General performance and functionality questions

isheff1 · 2014-07-12T01:04:05+00:00

Given the very limited developer resources on our side, we'll have to focus on Linux for the near future. And I encourage interested contributors to explore...

General performance and functionality questions

isheff1

(Resubmitting this as I was not subscribed before.)

I'm just getting started with OpenResty, and I'm trying to figure out which parts I should actually use.

I feel like there is a lot of overlapping functionality in some of the modules and a lot of choices that can be made.

For example, to MD5 a string I could:

Use ngx.md5: https://github.com/openresty/lua-nginx-module#ngxmd5

Use set_misc: https://github.com/openresty/set-misc-nginx-module

Use OpenResty's Lua module: https://github.com/openresty/lua-resty-string

Use a regular Lua module: http://openresty.org/#UsingLuaRocks

Same for caching, subrequests, routing, and a whole lot of other things. Normally I'd stick to the most expressive option, Lua, but for my purposes I really care about performance.

My question is: will a Lua module using LuaJIT and the cosocket API typically have the same performance as a full nginx module? Basically, does it not make a big difference what I decide to use?

Or, for performance, should I always be using pure nginx directives, and only resorting to Lua for functionality that I can't get from native nginx? One example of sticking to nginx directives would be using nginx's `map` instead of lots of Lua `if` statements, or using `location` instead of Lua routing, and also using existing nginx modules instead of Lua ones.

Additionally, if a Lua module is not bundled with OpenResty, how will I know if it's async-compatible and will take advantage of LuaJIT?

I know that it's better to profile first and ask questions later, but I'd just like to get a general idea for how I should start writing my code and my configuration to optimize for maximum performance.

Thanks.

agentzh

Hello!

On Fri, Jul 11, 2014 at 10:04 AM,  isheff1 wrote:
> For example, to MD5 a string I could:
>
> Use ngx.md5: https://github.com/openresty/lua-nginx-module#ngxmd5
> Use set_misc: https://github.com/openresty/set-misc-nginx-module
> Use OpenResty's Lua module: https://github.com/openresty/lua-resty-string
> Use a regular Lua module: http://openresty.org/#UsingLuaRocks
>

If you're using Lua, then use ngx.md5() from the ngx_lua core
(preferably with lua-resty-core) or the md5 module from
lua-resty-string. The former is good for one-run calculation and the
latter is good for streaming calculations (i.e., in chunks).

> My question is: will a Lua module using LuaJIT and the cosocket API
> typically have the same performance as a full nginx module?

Always use ngx_lua's cosocket and subrequest API for network I/O
otherwise it must block the nginx event loop and kill performance.

And the cosocket API is usually more efficient than doing subrequests
to other nginx upstream modules. The subrequest API (i.e.,
ngx.location.capture) is mainly for reusing existing nginx C modules.

> Or, for performance, should I always be using pure nginx directives, and
> only resorting to Lua for functionality that I can't get from native nginx?
> One example of sticking to nginx directives would be using nginx's `map`
> instead of lots of Lua `if` statements, or using `location` instead of Lua
> routing, and also using existing nginx modules instead of Lua ones.
>

It is recommended to use pure nginx.conf scripting (with minimal Lua)
for simple requirements and use as much Lua code as possible (with
minimal nginx.conf magic) for complicated things. But do not
interleave Lua and other nginx module directives heavily because going
across the boundary of Lua VM is always (kinda) expensive.

> Additionally, if a Lua module is not bundled with OpenResty, how will I know
> if it's async-compatible and will take advantage of LuaJIT?
>

You're using pure CPU bound Lua libraries, then it is almost always
safe to use as long as the CPU computation is not too intensive (like
taking hundreds of milliseconds or even longer).

For I/O related Lua libraries (like talking to some network services),
check if the library name is prefixed by "lua-resty-" and check the
documentation to see if it explicitly supports OpenResty or ngx_lua.

Say, if you're accidentally using a blocking Lua libraries (or nginx C
modules), you can always identify the blocking problem by running the
off-CPU flame graph tool
(https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu
) against your loaded nginx worker process.

> I know that it's better to profile first and ask questions later, but I'd
> just like to get a general idea for how I should start writing my code and
> my configuration to optimize for maximum performance.
>

See above :)

Regards,
-agentzh

isheff1

It is recommended to use pure nginx.conf scripting (with minimal Lua)
for simple requirements and use as much Lua code as possible (with
minimal nginx.conf magic) for complicated things. But do not
interleave Lua and other nginx module directives heavily because going
across the boundary of Lua VM is always (kinda) expensive.

Thank you, that's very helpful. I'll keep that in mind. And thanks for all the other explanations as well.

On Friday, July 11, 2014 6:26:59 PM UTC-4, agentzh wrote:

Hello!

On Fri, Jul 11, 2014 at 10:04 AM, isheff1 wrote:
> For example, to MD5 a string I could:
>
> Use ngx.md5: https://github.com/openresty/lua-nginx-module#ngxmd5
> Use set_misc: https://github.com/openresty/set-misc-nginx-module
> Use OpenResty's Lua module: https://github.com/openresty/lua-resty-string
> Use a regular Lua module: http://openresty.org/#UsingLuaRocks
>

If you're using Lua, then use ngx.md5() from the ngx_lua core
(preferably with lua-resty-core) or the md5 module from
lua-resty-string. The former is good for one-run calculation and the
latter is good for streaming calculations (i.e., in chunks).

> My question is: will a Lua module using LuaJIT and the cosocket API
> typically have the same performance as a full nginx module?

Always use ngx_lua's cosocket and subrequest API for network I/O
otherwise it must block the nginx event loop and kill performance.

And the cosocket API is usually more efficient than doing subrequests
to other nginx upstream modules. The subrequest API (i.e.,
ngx.location.capture) is mainly for reusing existing nginx C modules.

> Or, for performance, should I always be using pure nginx directives, and
> only resorting to Lua for functionality that I can't get from native nginx?
> One example of sticking to nginx directives would be using nginx's `map`
> instead of lots of Lua `if` statements, or using `location` instead of Lua
> routing, and also using existing nginx modules instead of Lua ones.
>

It is recommended to use pure nginx.conf scripting (with minimal Lua)
for simple requirements and use as much Lua code as possible (with
minimal nginx.conf magic) for complicated things. But do not
interleave Lua and other nginx module directives heavily because going
across the boundary of Lua VM is always (kinda) expensive.

> Additionally, if a Lua module is not bundled with OpenResty, how will I know
> if it's async-compatible and will take advantage of LuaJIT?
>

You're using pure CPU bound Lua libraries, then it is almost always
safe to use as long as the CPU computation is not too intensive (like
taking hundreds of milliseconds or even longer).

For I/O related Lua libraries (like talking to some network services),
check if the library name is prefixed by "lua-resty-" and check the
documentation to see if it explicitly supports OpenResty or ngx_lua.

Say, if you're accidentally using a blocking Lua libraries (or nginx C
modules), you can always identify the blocking problem by running the
off-CPU flame graph tool
(https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu
) against your loaded nginx worker process.

> I know that it's better to profile first and ask questions later, but I'd
> just like to get a general idea for how I should start writing my code and
> my configuration to optimize for maximum performance.
>

See above :)

Regards,
-agentzh