http://i.intma.in/images/2e27787dfaf5c000ae9a9a2ea859b6b3.pn...
yeah, this is a web guy I'm totally going to listen to
Apache 2.4 Faster Than Nginx?
41–44 of 44 posts
Re: Apache 2.4 Faster Than Nginx?
#42And the blog has been HN;FP'd!
I have to agree with people above me tho, the benchmarks are less then useful regarding more real-life uses but regardeless of that, he still spent time doing them we have to say thanks for atleast that :)
Re: Apache 2.4 Faster Than Nginx?
#43Earlier quoted context omitted.
"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 th…
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.…
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).
Re: Apache 2.4 Faster Than Nginx?
#44Apache is faster than NGINX. NGINX is faster than Apache. If that confuses you, then you don't understand http daemons. It's all about how you benchmark. This particular benchmark is 100% pointless and tells you nothing . He was performing the benchmark on one machine. In other words, all was local. You are never going to do that in production. What would be the point? In production, you have this thing called a netw…
Somebody do a benchmark with the client and server thousands of miles apart. That is not the right way to load test. You're not trying to determine how many pages a single client can request from a server. You're trying to isolate the performance variable. To do that, you test from a machine on the same network. The resulting values are how many requests the server can handle in a given period of time, regardless of…
> That is not the right way to load test.
False.
> You're not trying to determine how many pages a single client can request from a server.
True.
The reason you benchmark a server with a client from a thousand miles away is that you want to know what effect common Internet noise and delays will have on RAM and CPU consumption for the http daemon.
Conditions on a LAN are pretty close to ideal. Your router won't drop packets and will perform fairly well. That isn't anywhere close to true on the Internet as a whole. You do not want to push an http daemon to production that works like a champ on your LAN and has a meltdown in the real world.
You want to benchmark under as close to production conditions as you can. Period.