Hello!
On Thu, Dec 12, 2013 at 1:58 AM, jerome lafon wrote:
> I did some tests and this mechanism does not give me better performance than
> doing the 2 sql queries directly in my Lua code because I need to use the
> ngx.thread.wait() to be sure I have access to the sql result before the
> beginning of the process.
You need to define "performance" first when comparing.
Please note that running parallel DB queries will only help to reduce
the request's overall latency when the server is not reaching the
throughput limit (either in the database or in nginx). And generally
increasing concurrency usually reduce the throughput limit (at least a
bit).
When you load your nginx to its throughput limit, creating more DB
connections (to increase concurrency) will only make the performance
drop (both in throughput and in latency). So you need to understand
the performance implications here.
> But I think I will use ngx.thread.spawn in order to run asynchronous tasks
> without the need to wait for the end of the task like writing in REDIS to
> speed up the displaying of the output like that:
No, this will not really do what you want here. Because light threads
created by ngx.thread.spawn() are attached to the current request. The
current request won't complete until all its light threads exit. This
is explained in ngx_lua's official documentation, to quote,
"By default, the corresponding Nginx handler (e.g., rewrite_by_lua
handler) will not terminate until
1. both the "entry thread" and all the user "light threads" terminates,
2. a "light thread" (either the "entry thread" or a user "light
thread" aborts by calling ngx.exit, ngx.exec,ngx.redirect, or
ngx.req.set_uri(uri, true), or
3. the "entry thread" terminates with a Lua error.
"
To run asynchronous task detached completely from the current request,
you need the ngx.timer API instead:
https://github.com/chaoslawful/lua-nginx-module#ngxtimerat
Regards,
-agentzh
