Hello!

On Thu, Jan 9, 2014 at 5:35 AM, Andre Nathan wrote:
> However, as known,
> using the lua-sqlite3 library directly is not optimal because it would
> block the Nginx worker process.
>

Well, I suggest you benchmark the actual performance and measure the
actual blocking effect (We actually have systemtap-based tools to
measure the epoll loop blocking effect:
https://github.com/agentzh/stapxx#epoll-loop-blocking-distr and the
off-CPU flamegraph tool is very useful for determining the
contributors: https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-off-cpu
).

Basically if your database is in-memory, then the blocking effect
should be much smaller because no disk IO involved.

Even if you're using on-disk database, the blocking effect should be
quite small if your disks are fast (like modern SSD cards) and/or the
kernel's page cache's hit rate is high enough.

Nginx core's popular in-file http cache (used by proxy_cache,
fastcgi_cache, and etc) also involves blocking file IO system calls
and people are still enjoying it a lot ;)

It's worth noting that when you're using ngx_lua to embed a database
like SQLite, you should always cache the file descriptor to save
`open` and `close` system calls.

> My question is, is there a way to work around this in any way?

Ideally you should use (or write) a pthread based network service
frontend (be it TCP or just unix domain sockets) for SQLite and let
your Nginx talk to this network interface in a 100% nonblocking way.

> For
> example, creating a coroutine to run the lua-sqlite3 calls?
>

Basically Lua coroutines cannot work around blocking system calls. You
need real OS threads for that.

Regards,
-agentzh

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx