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