4 ms·

"Note in captions: (static file)... This is not realistic." It's reasonable if you're trying to test concurrent connection limits. "What you absolutely must d

by sciurus 15y ago

"Note in captions: (static file)... This is not realistic." It's reasonable if you're trying to test concurrent connection limits. "What you absolutely must do is benchmark a dynamic PHP-driven, with MySQL access, website." That's something nginx is also used for, and it's far from the only thing apache is used for. I agree that would be a useful benchmark, but it's not the only meaningful one. "you've only proven that Nginx can handle more concurrent requests for a single static file vs. Apache 2.4 (which is something we all already know to be true)." No, we didn't know this. This was testing apache 2.4's new event [0] MPM [1]. Arguably we still don't know this, since this apache configuration seems artificially limited and there's no comparison of the resource usage of apache and nginx. [0] http://httpd.apache.org/docs/2.4/mod/event.html http://httpd.apache.org/docs/2.4/mod/event.html [1] http://httpd.apache.org/docs/2.4/mpm.html http://httpd.apache.org/docs/2.4/mpm.html

mbreese 15y ago
You are dead on. If you're trying to determine which httpd is the fastest, you test it on static files. Take the dynamic part of a website out of the comparison. If you want to test something dynamic, make the test pull from many different files so that you can avoid caching. Next, if you want to test the PHP interfaces, you can do that, but this test setup was perfectly adequate for testing the speed of the daemon. (once the configuration issues are handled)
- powertower 15y ago
  Your testing methodology will fail horribly the moment the core component fails to produce results on real-world use cases, or scale up with the included modules that are required for it to even be called a modern day web-server. You eventually have to test the whole, not the part, unless you want to see benchmarks for useless/no-context metrics. On the other hand I do realize its fun to see tests like this, and they can even give you a bit of insight... For example, that Apache now comes close to competing with Nginx on static loads, especially for larger files (9KB vs 54KB).

by sciurus 15y ago

mbreese 15y ago

You are dead on. If you're trying to determine which httpd is the fastest, you test it on static files. Take the dynamic part of a website out of the comparison. If you want to test something dynamic, make the test pull from many different files so that you can avoid caching. Next, if you want to test the PHP interfaces, you can do that, but this test setup was perfectly adequate for testing the speed of the daemon. (once the configuration issues are handled)

powertower 15y ago
Your testing methodology will fail horribly the moment the core component fails to produce results on real-world use cases, or scale up with the included modules that are required for it to even be called a modern day web-server. You eventually have to test the whole, not the part, unless you want to see benchmarks for useless/no-context metrics. On the other hand I do realize its fun to see tests like this, and they can even give you a bit of insight... For example, that Apache now comes close to competing with Nginx on static loads, especially for larger files (9KB vs 54KB).