Live data from Hacker News

Let's Do Some Science: Zed's Test Stack for poll vs. epoll

sheddingbikes.com

1–10 of 45 posts

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#3
post #2

Duplicate. See lively discussion at http://news.ycombinator.com/item?id=1570694

Not exactly, this is where Zed presumably shows that using pipes is equivalent to real world testing and has nothing to do with using the loopback/localhost device.

Personally I think that's nonsense. I downloaded the code, checked it out, there is nothing in there that changes my mind on the whole thing, the meat is in the C code and it's the same as what was linked from the article. The rest is a wrapper script and some stuff to visualise the results, which are what he showed them to be. The premise that web servers have the majority of their fds active is where the issue lies.

FWIW I did some measuring and the results are pretty much in line with what I expected (though the spread is still puzzling, I really intend to find out the cause of that): http://news.ycombinator.com/item?id=1573145

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#5
Zed is probably right that poll is faster than epoll when all descriptors are active. There's no reason to doubt this since epoll has a callback for every file descriptor, while in poll, the OS only has to fill up an array of flags once per call.

http://lwn.net/Articles/14168/

However, I will have to side with jacquesm in saying that regular internet servers will usually benefit from epoll. It is unfathomable that web servers have lots of active file descriptors especially considering the "keep-alive" and that even broadband latency is an eternity for modern cpus to wait. On the other hand though, using poll makes sense for a heavily trafficked file server.

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#6
post #5

Zed is probably right that poll is faster than epoll when all descriptors are active. There's no reason to doubt this since epoll has a callback for every file descriptor, while in poll, the OS only has to fill up an array of flags once per call. http://lwn.net/Articles/14168/ However, I will have to side with jacquesm in saying that regular internet servers will usually benefit from epoll. It is unfathomable that we…

[deleted]

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#7
I'd be interested to see if the idea of switching between epoll and poll at 60% ATR would have too much overhead as to be impractical.

Re: > 60% active fd's being real-life or not, I don't really see what's the problem in wanting to handle that case in a project whose goal is basically to keep humming along nicely regardless of what you throw at it.

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#8
post #7

I'd be interested to see if the idea of switching between epoll and poll at 60% ATR would have too much overhead as to be impractical. Re: > 60% active fd's being real-life or not, I don't really see what's the problem in wanting to handle that case in a project whose goal is basically to keep humming along nicely regardless of what you throw at it.

Adding/removing from the poll() array is more or less free, but with epoll, you have to use epoll_ctl(), so you'd definitely want an hysteresis to avoid bouncing things around too much.

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#9
post #3
post #2

Duplicate. See lively discussion at http://news.ycombinator.com/item?id=1570694

Not exactly, this is where Zed presumably shows that using pipes is equivalent to real world testing and has nothing to do with using the loopback/localhost device. Personally I think that's nonsense. I downloaded the code, checked it out, there is nothing in there that changes my mind on the whole thing, the meat is in the C code and it's the same as what was linked from the article. The rest is a wrapper script and…

The massive thing that you're ignoring is that he's trying to make mongrel2 useful as more than a standard web server.

Sure, if you ignore that massively obvious piece of information, you have a point. But if you take it into account, you really don't have one at all.

As so often happens, you've spewed a lot of words, but said absolutely nothing of value.

Re: Let's Do Some Science: Zed's Test Stack for poll vs. epoll

#10
post #5

Zed is probably right that poll is faster than epoll when all descriptors are active. There's no reason to doubt this since epoll has a callback for every file descriptor, while in poll, the OS only has to fill up an array of flags once per call. http://lwn.net/Articles/14168/ However, I will have to side with jacquesm in saying that regular internet servers will usually benefit from epoll. It is unfathomable that we…

I believe that, other than in the new-for-the-sake-of-new sysadminning camp, people almost never start by deploying Mongrel. They deploy Apache, because it's easy (every distro comes with an excellent default set of LAMP packages, for obvious reasons.) Thus, Mongrel (or any other non-mindshare-majority server) is only sought out by those who don't like the one they've got—that is, by people who are not getting the performance they desire.

Mongrel is probably not used by Joe the VPS user, serving 20 simultaneous connections per hour, because Joe is doing just fine with the Apache install that came with his slice. Mongrel is deployed for high-traffic file servers, as the current weapon of choice.

It's very likely that that will continue to be its niche (though it will expand out somewhat as larger shared-hosting providers start to default to it), so it's very likely to mostly see use in high-ATR deployment scenarios. Under that assumption, Zed's experiment is solid. I would still like to see a prologue tacked on about the composition of the Mongrel user base, though, if Zed has it :)

Edit: rephrased to... sound less like Zed?

Post reply on HN