4 ms·

So let's take your assertions and take them apart: > the ones on dial up and on congested lines will get you every time. Do you have numbers on the dial-up us

by zedshaw 16y ago

So let's take your assertions and take them apart: > the ones on dial up and on congested lines will get you every time. Do you have numbers on the dial-up users for your server? My understanding is that there's far fewer, so this is bogus. Show evidence of high dial-up penetration first. > They keep the processes busy far longer than you'd want and you have to hit the 'poll' cycle far more frequently Again, you have no numbers on the active/total ratio in your server, so unless you do this statement doesn't refute what I found. I've presented evidence that just shows the math of O(N=active) / O(N=total) holds up. Simple math. The only way epoll wins for all load types is if it is as fast as poll all the time. My tests show it's not, which stands to reason since it's implemented using more syscalls than poll. > The impact of this is very easy to underestimate, and if you're benchmarking web servers for real world conditions you could do a lot worse than to run a test across a line that is congested on purpose. Again, you have no definition of "congestion". If you adopt a simple metric like ATR then we can talk. As it is, you (and everyone else) just throws around latency numbers like those matter when really the performance break is in the ATR. In addition, my numbers show the performance break being at about 60% ATR, so if you're saying that no server every goes above 60% activity levels then you're totally wrong. 60% is not completely unreasonable on a loaded server. But, I think you're missing a key point: You need both in a server like Mongrel2. I never said epoll sucks and poll rocks (since you probably didn't read the article). I said something very exact and measurable: > epoll is faster than poll when the active/total FD ratio is < 0.6, but poll is faster than epoll when the active/total ratio is > 0.6. If you don't think that's the case in "the real world" then go measure it and report back. That's the science part. I totally don't believe it yet myself, which is why I'm measuring it and showing the methods to everyone so they can confirm it for me.

bdr 16y ago
Read "on dial-up" as "slow". The argument depends only on there being a certain distribution of client speeds. It's not about dial-up in particular.
- zedshaw 16y ago
  And, if there's a distribution of speeds then you can measure the distribution and see what works best. Again, my challenge still stands: Measure it or STFU.
  - rortian 16y ago
    If only you practiced what you preached. Imagine the amount of self-righteous bile that your servers wouldn't serve.
    - zedshaw 16y ago
      I am practicing what I preach, you stupid 20%-er troll. That's why the whole blog post is full of measurements, testing hypotheses, and the assumption that I might be wrong. Because unlike you, I actually go do shit rather than spout off in a comment thread.
      - rortian 16y ago
        You may think you are. Far out. Why you think you can violate basic social norms, while others apparently support it, is beyond me.
        zedshaw 16y ago
        Basic social norms also involve not saying ruthless comments you wouldn't say to my face.
        rortian 16y ago
        Please, you are being ridiculous. I would tell you that you mostly produce self-righteous bile to your face or anywhere else. Do you say data or 'STFU' to people's face? You're arrogant and insecure. You lash out at others who question you. It's pretty sad. People make assertions all the time, as you do, that are difficult if not impossible to verify. Sometimes the data is too hard to produce. You've noted yourself that real-world server data would be hard to produce. You might say admit that and be more humble about the fact that you've analyzed a micro-benchmark.
jemfinch 16y ago
> Do you have numbers on the dial-up users for your server? My understanding is that there's far fewer, so this is bogus. Show evidence of high dial-up penetration first. He doesn't need to show that it's high, only that it's high enough to cause a significant contingent of ordinary webservers' requests to be lingering slow connections.
- zedshaw 16y ago
  I agree, but "high enough" is apparently just 60%. The standing question is, what's the actual level in different kinds of servers? In other words, I've given a metsric, ATR at 60% is the break even point for poll vs. epoll. So far the only responses I've got haven't even tried to give out a metric, let alone say what their actual ATR is but they claim that it's low. I'm a scientist, so in the same way I don't believe my own research, I don't believe their rhetoric.
  - jacquesm 16y ago
    > I'm a scientist I've never come across a scientist that took criticism of their work the way you do and that responded in the way you do. Shouting down, deriding, insulting and in general being a jerk to those that don't agree with you because 'you're a scientist' is not the way of science.
    - starkfist 16y ago
      I dunno, that is how a lot of scientists I know interact with people. :/
      - jacquesm 16y ago
        That's pretty sad.
    - zedshaw 16y ago
      I'm shouting you down because you're a FUD slinging troll. Very first thing you did was immediately reply to every branch of the comments with your agenda. I actually have no idea what your problem is, since I'm just presenting some information and working on my own software with it, but you've got some weird "epoll religion" you like to spread. So, consider me the Richard Dawkins of epoll.
jacquesm 16y ago
So, here are the numbers from one of the webservers that I instrumented to log the active-to-total ratio over a couple of hours. The webserver is custom job called yawwws (yet-another-www-server) that is used to serve up a variety of bits and pieces for a high traffic website, typically the requests are very short in nature (a 500 byte request followed by a < 10K answer). After about two hours of running the active-to-total ratio varied between 10% to 40% for 5 minute intervals, with the majority of the 5 minute buckets around the 30% mark. I'm actually quite surprised at the spread. The bigger portion of the time seems to be spent waiting for the clients to send the request, most if not all of the output data should fit in the TCP output buffers, so that actually skews the results upwards, for longer running requests sending more data to the clients the active-to-total ratios would probably be a bit lower. So 10% to 40% of all the sockets were active at any given time, the rest was idle, waiting for data to be received or for buffer space to be freed up so data could be written. In this situation epoll would be faster than poll because epoll only sends the user process those fds that it actually has to deal with rather than all of them, so the loop that takes the output of the system call will have less iterations. So, as I wrote before, I think the typical web server is, when it is dealing with the client facing side more often than not waiting for the client to do something, and it seems that on my server that hasn't changed since I last looked at it. This server runs with keepalive off. Switching it on will most likely make the active-to-total ratio dramatically lower but I don't feel like pissing off a large number of users just to see how bad it could get. There is a good chance that my socket pool will turn out to be too small to do this without damage. Chances are that for different workloads the percentages will vary but this setup is fairly typical (single threaded server, all requests served from memory) so I wouldn't expect to see too much variation on different sites, and if there is variation I'd expect it to go down rather than up. If I get a chance I'll re-run the test on some other websites to see if the numbers come out comparable or are wildly different.

by zedshaw 16y ago

bdr 16y ago

Read "on dial-up" as "slow". The argument depends only on there being a certain distribution of client speeds. It's not about dial-up in particular.

zedshaw 16y ago
And, if there's a distribution of speeds then you can measure the distribution and see what works best. Again, my challenge still stands: Measure it or STFU.
- rortian 16y ago
  If only you practiced what you preached. Imagine the amount of self-righteous bile that your servers wouldn't serve.
  - zedshaw 16y ago
    I am practicing what I preach, you stupid 20%-er troll. That's why the whole blog post is full of measurements, testing hypotheses, and the assumption that I might be wrong. Because unlike you, I actually go do shit rather than spout off in a comment thread.
    - rortian 16y ago
      You may think you are. Far out. Why you think you can violate basic social norms, while others apparently support it, is beyond me.
      - zedshaw 16y ago
        Basic social norms also involve not saying ruthless comments you wouldn't say to my face.
        rortian 16y ago
        Please, you are being ridiculous. I would tell you that you mostly produce self-righteous bile to your face or anywhere else. Do you say data or 'STFU' to people's face? You're arrogant and insecure. You lash out at others who question you. It's pretty sad. People make assertions all the time, as you do, that are difficult if not impossible to verify. Sometimes the data is too hard to produce. You've noted yourself that real-world server data would be hard to produce. You might say admit that and be more humble about the fact that you've analyzed a micro-benchmark.

jemfinch 16y ago

> Do you have numbers on the dial-up users for your server? My understanding is that there's far fewer, so this is bogus. Show evidence of high dial-up penetration first. He doesn't need to show that it's high, only that it's high enough to cause a significant contingent of ordinary webservers' requests to be lingering slow connections.

zedshaw 16y ago
I agree, but "high enough" is apparently just 60%. The standing question is, what's the actual level in different kinds of servers? In other words, I've given a metsric, ATR at 60% is the break even point for poll vs. epoll. So far the only responses I've got haven't even tried to give out a metric, let alone say what their actual ATR is but they claim that it's low. I'm a scientist, so in the same way I don't believe my own research, I don't believe their rhetoric.
- jacquesm 16y ago
  > I'm a scientist I've never come across a scientist that took criticism of their work the way you do and that responded in the way you do. Shouting down, deriding, insulting and in general being a jerk to those that don't agree with you because 'you're a scientist' is not the way of science.
  - starkfist 16y ago
    I dunno, that is how a lot of scientists I know interact with people. :/
    - jacquesm 16y ago
      That's pretty sad.
  - zedshaw 16y ago
    I'm shouting you down because you're a FUD slinging troll. Very first thing you did was immediately reply to every branch of the comments with your agenda. I actually have no idea what your problem is, since I'm just presenting some information and working on my own software with it, but you've got some weird "epoll religion" you like to spread. So, consider me the Richard Dawkins of epoll.

jacquesm 16y ago

So, here are the numbers from one of the webservers that I instrumented to log the active-to-total ratio over a couple of hours. The webserver is custom job called yawwws (yet-another-www-server) that is used to serve up a variety of bits and pieces for a high traffic website, typically the requests are very short in nature (a 500 byte request followed by a < 10K answer). After about two hours of running the active-to-total ratio varied between 10% to 40% for 5 minute intervals, with the majority of the 5 minute buckets around the 30% mark. I'm actually quite surprised at the spread. The bigger portion of the time seems to be spent waiting for the clients to send the request, most if not all of the output data should fit in the TCP output buffers, so that actually skews the results upwards, for longer running requests sending more data to the clients the active-to-total ratios would probably be a bit lower. So 10% to 40% of all the sockets were active at any given time, the rest was idle, waiting for data to be received or for buffer space to be freed up so data could be written. In this situation epoll would be faster than poll because epoll only sends the user process those fds that it actually has to deal with rather than all of them, so the loop that takes the output of the system call will have less iterations. So, as I wrote before, I think the typical web server is, when it is dealing with the client facing side more often than not waiting for the client to do something, and it seems that on my server that hasn't changed since I last looked at it. This server runs with keepalive off. Switching it on will most likely make the active-to-total ratio dramatically lower but I don't feel like pissing off a large number of users just to see how bad it could get. There is a good chance that my socket pool will turn out to be too small to do this without damage. Chances are that for different workloads the percentages will vary but this setup is fairly typical (single threaded server, all requests served from memory) so I wouldn't expect to see too much variation on different sites, and if there is variation I'd expect it to go down rather than up. If I get a chance I'll re-run the test on some other websites to see if the numbers come out comparable or are wildly different.