If only the nginx-provided rpm build was built --with-threads.
Boosting Nginx Performance with Thread Pools
41–48 of 48 posts
Re: Boosting Nginx Performance with Thread Pools
#42Earlier quoted context omitted.
What if Linux had a great asynchronous interface for reading files and FreeBSD had a terrible one ? Would NGINX team have bothered to implement this ?
Originally, as Igor has said in many talks, Nginx was written for FreeBSD, and supports what FreeBSD supports, and the Linux port has historically managed as it could. This is a case of actually adding something for Linux specifically, which is unuusual. So the answer is it probably would have been implmented years ago if that was the case.
Originally. But the focus has shifted since then. There are a number of Linux-addicted developers in the team now.
Re: Boosting Nginx Performance with Thread Pools
#43Thanks, we run a few sites at work that might benefit from implementing this.
Re: Boosting Nginx Performance with Thread Pools
#44It is really unfortunate that Linux does not do proper async disk IO. Then again, for lots of websites, the static assets stores on disk fit in the OS cache so the boost won't really be nearly as big.
I'm not sure what you really mean by this. Linux has supported non-blocking I/O using select and poll since at least 2.4. 2.6 even added support for epoll, which scales even further since the callbacks are O(1).
It's a fairly common practice to spawn 2n processes/threads (n processors) to allow half to block on I/O and system calls though.
Re: Boosting Nginx Performance with Thread Pools
#45Re: Boosting Nginx Performance with Thread Pools
#46That Flare Mobile crap on this site is constantly applying zoom CSS attributes and vertically centering the useless sidebar share buttons making the reading experience very horrible. The page freezes momentarily anytime a scroll event is triggered. And, I'm not even using a mobile device! A bit ironic since this is an article about reducing blocking for improving performance.
Hi there - I work on Flare. Could you let me know what phone/OS you're using, so I can take a quick look? jason [at] filament (dot) io. Thanks very much!
Re: Boosting Nginx Performance with Thread Pools
#47It is really unfortunate that Linux does not do proper async disk IO. Then again, for lots of websites, the static assets stores on disk fit in the OS cache so the boost won't really be nearly as big.
I'm not sure what you really mean by this. Linux has supported non-blocking I/O using select and poll since at least 2.4. 2.6 even added support for epoll , which scales even further since the callbacks are O(1) . It's a fairly common practice to spawn 2n processes/threads ( n processors) to allow half to block on I/O and system calls though.
Well, TFA talks about Linux not having great support for async IO for the filesystem. You can use O_DIRECT and get async IO that way, but that completely bypasses the OS cache, so it's not a great way to do it, at least not for nginx. Just read the article to see the details.
Note that kqueue(2) in BSD-land supports a unified interface for async IO for both sockets and files, so you can have a proper event loop without having to resort to reading files in a thread pool. If Linux had something similar, a nginx wouldn't need to integrate a threadpool for this (though it might for other things, such as CPU-intensive plugins).
Re: Boosting Nginx Performance with Thread Pools
#48Earlier quoted context omitted.
I'm not sure what you really mean by this. Linux has supported non-blocking I/O using select and poll since at least 2.4. 2.6 even added support for epoll , which scales even further since the callbacks are O(1) . It's a fairly common practice to spawn 2n processes/threads ( n processors) to allow half to block on I/O and system calls though.
Well, TFA talks about Linux not having great support for async IO for the filesystem. You can use O_DIRECT and get async IO that way, but that completely bypasses the OS cache, so it's not a great way to do it, at least not for nginx. Just read the article to see the details. Note that kqueue(2) in BSD-land supports a unified interface for async IO for both sockets and files, so you can have a proper event loop witho…
The nginx threadpools aren't strictly for I/O. One of the other major issues TFA mentions is that plugins don't use epoll/kqueue, and they block (with all the associated performance costs).
The detail I apparently skipped is that uncached file reads aren't handled uniformly through epoll (which I'm surprised about). I don't see why files should be handled any differently than sockets. etc... in regard to non-blocking I/O using epoll.
Although, my issue is that everyone tends to look to methods starting with aio_ to do asynchronous I/O. Those are fairly bad interfaces (POSIX AIO) and inefficient (effectively threadpools). Using the nginx model with an epoll/kqueue event loop is a better architecture.