23 ms·

I think all emphasis on server software speed is overrated. In pretty much everything but hello world, the vast majority of the time is spent inside the web app

I think all emphasis on server software speed is overrated. In pretty much everything but hello world, the vast majority of the time is spent inside the web app, not in the server. Yes, lowering the web server overhead is a good thing. But I think in most cases it's already so low that further reducing this overhead results in no noticeable impact in real-life scenarios. At some point you'll just be benchmarking how fast the kernel is at doing connect(), read() and write() - in other words how fast your computer can do nothing. For example, let's consider this thought experiment: Someone here mentioned Mongrel2 getting 4000 req/sec. Let's replace the name "Mongrel2" with "Server A" because this thought experiment is not limited to Mongrel2, but all servers. I assume he's benchmarking a hello world app on his laptop. Suppose that a hypothetical Server B gets "only" 2000 req/sec. One might now (mistakenly) conclude that: - Server B is a lot slower. - One should use Server A instead of Server B in high-traffic production environments. Now put Server A behind HAProxy. HAproxy is known as a high-performance HTTP proxy server with minimal overhead. Benchmark this setup, and watch req/sec drop to about 2000-3000 (when benchmarked on a typical dual core laptop). What just happened? Server B appears to be very slow. But the reality is that both Server A and Server B are so fast that doing even a minimum amount of extra work will have a significant effect on the req/sec number. In this case, the overhead of an extra context switch and a read()/write() call to the kernel is already enough to make the req/sec number drop by half. Any reasonably complex web app logic will make the number drop so much that the performance difference between the different servers become negligible.

sliverstorm 16y ago
Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.
- njharman 16y ago
  Because increasing benchmark speed provides no business value (assuming your business isn't self-promotion, getting into flamewars, etc). There's a extremely well known saying that speaks to this issue, goes something like "Preoptimiztion is root of all evil."
- FooBarWidget 16y ago
  Because at some point you will pass the point of diminishing returns. Suppose 3% of the time is spent in the server, and 97% in the web app. Do you really want to spend 200 hours trying to reduce that 3% to 2.5% instead of spending 10 hours on making your app twice as fast? You've made the server 20% faster, but what have you really gained in practice when you look at the overall picture? Even assuming unlimited developer resources, will you really notice a 0.5% difference in production, especially when taking things like network latency into account? My point is that hyping over raw performance is misleading at best. If performance is the only thing that matters then we wouldn't have operating systems with abstractions - everybody would program against the bare metal in assembly. One should weight the pros and cons carefully and reach a balanced trade-off.
  - d0mine 16y ago
    Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law
  - yashh 16y ago
    Totally agree with you. You dont really get 1000's of reqs/sec in a real world environment. All you need is a good server which is fast and memory efficient. Rest of the efforts should be focussed on the webapp side, more importantly DB. If you can work on your IO you will have a fast and efficient application.
  - detst 16y ago
    > 200 hours trying to reduce that 3% to 2.5% It's about progression over time. If someone didn't do it, we'd be leaving significant performance gains behind. That means more servers, more electricity and more money for everyone. I'm not going to do that for my app but it's nice that there are people making these improvements for the benefit of everyone that uses their server. When you take into account many small improvements, across all deployments, over time, they can and do add up to significant improvements.

sliverstorm 16y ago

Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.

njharman 16y ago
Because increasing benchmark speed provides no business value (assuming your business isn't self-promotion, getting into flamewars, etc). There's a extremely well known saying that speaks to this issue, goes something like "Preoptimiztion is root of all evil."
FooBarWidget 16y ago
Because at some point you will pass the point of diminishing returns. Suppose 3% of the time is spent in the server, and 97% in the web app. Do you really want to spend 200 hours trying to reduce that 3% to 2.5% instead of spending 10 hours on making your app twice as fast? You've made the server 20% faster, but what have you really gained in practice when you look at the overall picture? Even assuming unlimited developer resources, will you really notice a 0.5% difference in production, especially when taking things like network latency into account? My point is that hyping over raw performance is misleading at best. If performance is the only thing that matters then we wouldn't have operating systems with abstractions - everybody would program against the bare metal in assembly. One should weight the pros and cons carefully and reach a balanced trade-off.
- d0mine 16y ago
  Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law
- yashh 16y ago
  Totally agree with you. You dont really get 1000's of reqs/sec in a real world environment. All you need is a good server which is fast and memory efficient. Rest of the efforts should be focussed on the webapp side, more importantly DB. If you can work on your IO you will have a fast and efficient application.
- detst 16y ago
  > 200 hours trying to reduce that 3% to 2.5% It's about progression over time. If someone didn't do it, we'd be leaving significant performance gains behind. That means more servers, more electricity and more money for everyone. I'm not going to do that for my app but it's nice that there are people making these improvements for the benefit of everyone that uses their server. When you take into account many small improvements, across all deployments, over time, they can and do add up to significant improvements.