Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boosting Nginx Performance with Thread Pools

nginx.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Boosting Nginx Performance with Thread Pools

#31

Post by noselasd »

istvan__ wrote: post #27
caf wrote: post #15

Earlier quoted context omitted.

Remember that processes in (D)isk Wait state count towards the load average even though they are not running or runnable.

As well as network IO. This is why just by the load you can't tell what is going on and this is exactly the reason why I don't like it too much in production. A box should do a have a smooth 15minutes normalized load over time. (If your workload changes you can do autoscaling, I think we used the normalized load as the metric for scaling up and down).

At least according to the linux documentation, network IO is NOT part of the load average, only processes waiting for disk IO and runnable processes.

Re: Boosting Nginx Performance with Thread Pools

#32

Post by gregham »

nly wrote: post #22

Hardly exciting stuff, async libraries have been doing this for things like DNS queries (where there's no portable non-blocking API) for decades. Good for Nginx addon devs I guess.

Will you be exited if I tell you that nginx doing async DNS queries for decades without threads? It has it's own async resolver implementation.

Re: Boosting Nginx Performance with Thread Pools

#35

Post by simula67 »

antonios wrote: post #34

"On the other hand, users of FreeBSD don’t need to worry at all. FreeBSD already has a sufficiently good asynchronous interface for reading files, which you should use instead of thread pools." Great to hear that.

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 ?

Re: Boosting Nginx Performance with Thread Pools

#36

Post by justincormack »

simula67 wrote: post #35
antonios wrote: post #34

"On the other hand, users of FreeBSD don’t need to worry at all. FreeBSD already has a sufficiently good asynchronous interface for reading files, which you should use instead of thread pools." Great to hear that.

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.

Re: Boosting Nginx Performance with Thread Pools

#37

Post by jimjag »

smegel wrote: post #5

I think this would have been much better titled "Boosting NGINX Performance 9x with Asynchronous wrappers around blocking system calls". Most people when hearing about "thread pools" in the context of a web-server think about using multiple threads for handling separate requests, which is NOT what this is about. It is using threads to enable some blocking syscalls (read and sendfile) to run asynchronously from the ma…

As well as an Apache httpd MPM: Event

Re: Boosting Nginx Performance with Thread Pools

#38

Post by coldtea »

girvo wrote: post #29
nly wrote: post #22

Hardly exciting stuff, async libraries have been doing this for things like DNS queries (where there's no portable non-blocking API) for decades. Good for Nginx addon devs I guess.

Just because it's been done in other tools doesn't make it "hardly exciting" when an often-used tool that was lacking a feature adds it.

He conflated exciting with "new development in computer science".

Re: Boosting Nginx Performance with Thread Pools

#40

Post by vidarh »

dschiptsov wrote: post #14
SethMurphy wrote: post #2

Great explanation of an event driven web server. Helped me understand ome of the benefits of the mongrel2 architecture that separates the tasks needed to be done completely by using ØMQ as the mechanism to decouple the connection handling from the message handling of the request.

While asynchronous messaging is generally a good idea, using a messaging middleware seem to be an overkill. One should use smallest hammer for the job. Thread is a wrong idea in the first place - by broking isolation of processes (share nothing principle) they brought in the whole new class of problems with locking and synchronization. Only threads that share nothing is a reasonable choice, but without sharing the wh…

0MQ isn't a messaging middleware. It's point to point (unless you build your own middleware).
Post reply on HN