URL rewrite : efficient way

rohit.c.joshi · 2014-09-06T19:31:30+00:00

Yes, it was a typo. I am using rewrite_by_lua_file. Problem is resolved by using your solution. Thanks. upstream foo.com&nbs...

URL rewrite : efficient way

rohit.c.joshi

Hello,
I am using OpenResty as a reverse proxy server which will route requests to back end servers based on URL mappings.

We have hundreds of services with each one having multiple Uris  categories under parent root context.

I would like to retrieve these entries from external database and cache it instead of defining in nginx configuration file.

/root1/abc  /abc-service
/root1/abc/(.*)/xyz   /xyz-service
/root/bca bca-service
......
.....
/root2/qwe qwe-service 
/root2/asd ass-service
.....
.....


We have around 15 root levels with each having 5 to 20 mapping entries.

What would be the most efficient way of rewriting these Uris?

Here are my thoughts:
In access_by_lua :
1. Retrieve these entries from SQL backend and convert into json string

2. Cache json string into shared dict cache.

In rewrite_by_lua:

3. Convert json to lua nested table with first index as root and 2nd level with mappings

4. Get the root from request uri, use it as key to get mappings

5. Iterate over mappings , perform regex to find associated service. Will this be efficient? Compared to nginx maps directive?

6. Get uri suffix (after root level) from request uri and append to service

7. Set this uri to nginx upstream variable which is used in proxy_pass. 

Thanks

brian

Are the uri's such that you could use a trie? That would be more efficient than using a list if regex's

Sent from my iPhone

> On Sep 6, 2014, at 7:31 AM, RJoshi <rohit....@gmail.com> wrote:
> 
> Hello,
> I am using OpenResty as a reverse proxy server which will route requests to back end servers based on URL mappings.
> 
> We have hundreds of services with each one having multiple Uris  categories under parent root context.
> 
> I would like to retrieve these entries from external database and cache it instead of defining in nginx configuration file.
> 
> /root1/abc  /abc-service
> /root1/abc/(.*)/xyz   /xyz-service
> /root/bca bca-service
> ......
> .....
> /root2/qwe qwe-service 
> /root2/asd ass-service
> .....
> .....
> 
> 
> We have around 15 root levels with each having 5 to 20 mapping entries.
> 
> What would be the most efficient way of rewriting these Uris?
> 
> Here are my thoughts:
> In access_by_lua :
> 1. Retrieve these entries from SQL backend and convert into json string
> 
> 2. Cache json string into shared dict cache.
> 
> In rewrite_by_lua:
> 
> 3. Convert json to lua nested table with first index as root and 2nd level with mappings
> 
> 4. Get the root from request uri, use it as key to get mappings
> 
> 5. Iterate over mappings , perform regex to find associated service. Will this be efficient? Compared to nginx maps directive?
> 
> 6. Get uri suffix (after root level) from request uri and append to service
> 
> 7. Set this uri to nginx upstream variable which is used in proxy_pass. 
> 
> Thanks.

rohit.c.joshi

No, these are rest Uris in upstream and all of them are valid resources so tries will not work.

> On Sep 6, 2014, at 10:05 AM, Brian Akins <br...@akins.org> wrote:
> 
> Are the uri's such that you could use a trie? That would be more efficient than using a list if regex's
> 
> Sent from my iPhone
> 
>> On Sep 6, 2014, at 7:31 AM, RJoshi <rohit....@gmail.com> wrote:
>> 
>> Hello,
>> I am using OpenResty as a reverse proxy server which will route requests to back end servers based on URL mappings.
>> 
>> We have hundreds of services with each one having multiple Uris  categories under parent root context.
>> 
>> I would like to retrieve these entries from external database and cache it instead of defining in nginx configuration file.
>> 
>> /root1/abc  /abc-service
>> /root1/abc/(.*)/xyz   /xyz-service
>> /root/bca bca-service
>> ......
>> .....
>> /root2/qwe qwe-service 
>> /root2/asd ass-service
>> .....
>> .....
>> 
>> 
>> We have around 15 root levels with each having 5 to 20 mapping entries.
>> 
>> What would be the most efficient way of rewriting these Uris?
>> 
>> Here are my thoughts:
>> In access_by_lua :
>> 1. Retrieve these entries from SQL backend and convert into json string
>> 
>> 2. Cache json string into shared dict cache.
>> 
>> In rewrite_by_lua:
>> 
>> 3. Convert json to lua nested table with first index as root and 2nd level with mappings
>> 
>> 4. Get the root from request uri, use it as key to get mappings
>> 
>> 5. Iterate over mappings , perform regex to find associated service. Will this be efficient? Compared to nginx maps directive?
>> 
>> 6. Get uri suffix (after root level) from request uri and append to service
>> 
>> 7. Set this uri to nginx upstream variable which is used in proxy_pass. 
>> 
>> Thanks.

agentzh

Hello!

On Sat, Sep 6, 2014 at 4:31 AM, RJoshi wrote:
> Here are my thoughts:
> In access_by_lua :
[...]
>
> In rewrite_by_lua:
>

Several suggestions:

1. Do not use separate Lua handlers for this, because it has extra
overhead. I don't see why you cannot just merge access_by_lua and
rewrite_by_lua into a single handler.

2. Better add another caching layer via lua-resty-lrucache while still
caching the original JSON strings in lua_shared_dict. See

    https://github.com/openresty/lua-resty-lrucache

This way you can reduce the nontrivial overhead of decoding JSON in
every request (this is gonna be hot!).

3. Because you are having only 15 ~ 20 patterns to match under each
"root" prefix, optimizations like trie and DFA may not give measurable
benefit. Iterating through a list of regexes via the ngx.re API should
be fast enough or even faster. Furthermore, if you're not making use
of more than 1 submatch captures, then you should use ngx.re.find()
instead. Even if you have to use ngx.re.match that returns a match
table, you should recycle the match table via the argument. If you
have more than hundreds of entries under each "root" prefix, then you
should consider those more advanced algorithms.

4. Try using lua-resty-core to make most of your Lua code JIT compiled
by LuaJIT v2.1:

    https://github.com/openresty/lua-resty-core

This usually makes a difference :)

5. Always use the flame graph tools to profile your nginx under load
(for example, loaded by weighttp or ab) to analyze real hot spots:

    https://github.com/openresty/stapxx#lj-lua-stacks

    https://github.com/openresty/nginx-systemtap-toolkit#sample-bt

Specifically optimizing anything that is not showing hot on the flame
graphs are very likely to be "premature optimizations" which should
always be avoided :)

Regards,
-agentzh

rohit.c.joshi

Thanks agentzh.

1. I combined both content_by_lua and rewrite_by_lua into rewrite_by_lua_file. Thx

2. lua-resty-lrucache and json convesion per request:

Do you think it would be better to retrieve rewrite mappings from database , convert into to lua string ( instead of json string) , store into lua_shared_dict and also use Lua loadstring to convert into Lua table and then set as a global variable per Lua VM/worker?

Check if a Lua string exists in the cache and if yes than reuse Lua tables. If not, retrieve again and override a global variable with new lua mappings table.

The reason is these mappings doesn't change very often (changes only when new services are deployed on the backend) so overhead is only for the first request per nginx worker and mostly done at night (low traffic).

3. For now, will go with ngx.re.match and will see if advance algorithms are needed.

4. I am using lua-resty-code

5. Will try flame graf and share performance results.

Thank again.

Regards

On Saturday, 6 September 2014 15:14:40 UTC-4, agentzh wrote:

Hello!

On Sat, Sep 6, 2014 at 4:31 AM, RJoshi wrote:
> Here are my thoughts:
> In access_by_lua :
[...]
>
> In rewrite_by_lua:
>

Several suggestions:

1. Do not use separate Lua handlers for this, because it has extra
overhead. I don't see why you cannot just merge access_by_lua and
rewrite_by_lua into a single handler.

2. Better add another caching layer via lua-resty-lrucache while still
caching the original JSON strings in lua_shared_dict. See

https://github.com/openresty/lua-resty-lrucache

This way you can reduce the nontrivial overhead of decoding JSON in
every request (this is gonna be hot!).

3. Because you are having only 15 ~ 20 patterns to match under each
"root" prefix, optimizations like trie and DFA may not give measurable
benefit. Iterating through a list of regexes via the ngx.re API should
be fast enough or even faster. Furthermore, if you're not making use
of more than 1 submatch captures, then you should use ngx.re.find()
instead. Even if you have to use ngx.re.match that returns a match
table, you should recycle the match table via the argument. If you
have more than hundreds of entries under each "root" prefix, then you
should consider those more advanced algorithms.

4. Try using lua-resty-core to make most of your Lua code JIT compiled
by LuaJIT v2.1:

https://github.com/openresty/lua-resty-core

This usually makes a difference :)

5. Always use the flame graph tools to profile your nginx under load
(for example, loaded by weighttp or ab) to analyze real hot spots:

https://github.com/openresty/stapxx#lj-lua-stacks

https://github.com/openresty/nginx-systemtap-toolkit#sample-bt

Specifically optimizing anything that is not showing hot on the flame
graphs are very likely to be "premature optimizations" which should
always be avoided :)

Regards,
-agentzh

agentzh

Hello!

On Sun, Sep 7, 2014 at 7:52 AM, RJoshi wrote:
> 2.   lua-resty-lrucache and json convesion per request:
> Do you think it would be better to retrieve rewrite mappings from database ,
> convert into to lua string ( instead of json string) , store into
> lua_shared_dict and also use  Lua  loadstring to convert into Lua table and
> then set as a global variable per Lua VM/worker?
>

You could. But Lua source strings are not very good for data exchange
among different programming languages :)

> Check if a Lua string exists in the cache and if yes than reuse Lua tables.
> If not, retrieve again and override a global variable with new lua mappings
> table.

Do not use global variables unless you always provide your own global
environment table via setfenv(). Otherwise it can pollute the global
namespace and is a bad practice.

> The reason is these mappings doesn't change very often (changes only when
> new services are deployed on the backend) so overhead is only for the first
> request per nginx worker and mostly done at night (low traffic).
>

Looking good.

> 5. Will try flame graf and share performance results.
>

Looking forward to that :)

Regards,
-agentzh

rohit.c.joshi

Ok, will use resty lru cache.

Thx

> On Sep 7, 2014, at 5:39 PM, "Yichun Zhang (agentzh)" <age...@gmail.com> wrote:
> 
> Hello!
> 
>> On Sun, Sep 7, 2014 at 7:52 AM, RJoshi wrote:
>> 2.   lua-resty-lrucache and json convesion per request:
>> Do you think it would be better to retrieve rewrite mappings from database ,
>> convert into to lua string ( instead of json string) , store into
>> lua_shared_dict and also use  Lua  loadstring to convert into Lua table and
>> then set as a global variable per Lua VM/worker?
> 
> You could. But Lua source strings are not very good for data exchange
> among different programming languages :)
> 
>> Check if a Lua string exists in the cache and if yes than reuse Lua tables.
>> If not, retrieve again and override a global variable with new lua mappings
>> table.
> 
> Do not use global variables unless you always provide your own global
> environment table via setfenv(). Otherwise it can pollute the global
> namespace and is a bad practice.
> 
>> The reason is these mappings doesn't change very often (changes only when
>> new services are deployed on the backend) so overhead is only for the first
>> request per nginx worker and mostly done at night (low traffic).
> 
> Looking good.
> 
>> 5. Will try flame graf and share performance results.
> 
> Looking forward to that :)
> 
> Regards,
> -agentzh.