6 ms·

Note in captions: (static file). He might as well have benchmarked Apache against an FTP server. Hitting the same HTML page/file over and over is not realisti

Note in captions: (static file). He might as well have benchmarked Apache against an FTP server. Hitting the same HTML page/file over and over is not realistic. There is so much more to a web-server than this. What you absolutely must do is benchmark a dynamic PHP-driven, with MySQL access, website. Because that's what Apache is mostly used for (rarely for file serving). And I don't mean the first page only. But the entire website using a stress profile that mimics real world usage (including writing to the database). Then you'll get results that mean something. As it is right now, this test has 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).

gtaylor 15y ago
This. Good grief, what a leap of logic this entire benchmark is.
- nteon 15y ago
  why? just because his use case is different from yours? some people use apache for fronting dynamic requests, and nginx for static serving. It would be interesting to see if apache has become competitive at serving static resources and I could drop nginx from my servers.
kijin 15y ago
Good point, but I don't think people only ever use Apache for PHP and MySQL.
- mst 15y ago
  I'm certain they don't, but it doesn't seem like a terrible lowest common denominator to me - certainly it'd be a better one than pure static file serving from the point of view of the workloads I normally deal with in production.
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).
scottbruin 15y ago
I dunno, we separate out static file vs. needs-to-go-to-Tomcat requests at our HAProxy so I'm actually interested in what simply performs best serving static files. I can't imagine we're the only ones to have this need.

gtaylor 15y ago

This. Good grief, what a leap of logic this entire benchmark is.

nteon 15y ago
why? just because his use case is different from yours? some people use apache for fronting dynamic requests, and nginx for static serving. It would be interesting to see if apache has become competitive at serving static resources and I could drop nginx from my servers.

kijin 15y ago

Good point, but I don't think people only ever use Apache for PHP and MySQL.

mst 15y ago
I'm certain they don't, but it doesn't seem like a terrible lowest common denominator to me - certainly it'd be a better one than pure static file serving from the point of view of the workloads I normally deal with in production.

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).

scottbruin 15y ago

I dunno, we separate out static file vs. needs-to-go-to-Tomcat requests at our HAProxy so I'm actually interested in what simply performs best serving static files. I can't imagine we're the only ones to have this need.