Performance of Apache 2.4 with the event MPM compared to Nginx

Gary Mort

Are you running Apache Event MPM + mod_php or Apache Event MPM + fastcgi?

Apache Event MPM + mod_php really does not buy much[I’m not really sure how it would buy anything actually]. With mod_php each Apache thread is going to execute PHP directly. So it makes almost zero use of libEvent, libUv or whatever flavor of the month.

Using event, the idea is that when it comes time to execute a cgi script, the processing is passed off to a separate server and the Apache worker thread goes to sleep until there is a response or a timeout. This means that the libEvent server can process many more requests as since it can run more workers.

This is how nginx works. Nginx was built to use libevent from the start which helps it to be so screamingly fast. So to test it, you have to use Apache Event MPM + fastcgi. In this case, the performance for service PHP will be based on how the web server handles it’s worker threads.

Moreover, not serving longer running larger content generating scripts is not really useful. Since the whole purpose of libevent is to allow more processes while waiting for results, server 100byte fast results means your not testing how the server handles having to suddenly handle 100 17k different responses from FPM. Here it will be wildly different since Nginx counts on persistent fpm connections by default and Apache counts on unique ones. So 100 17k results all coming over a single fastcgi connection will be processed differently then 100 17k results over 100 sockets.

Nginx also performs some special caching tricks on small responses. Even though you had still had to transfer the same 100bytes over and over to Nginx, once nginx receives it – based on the hash of the data it will send the data from it’s copy in cache – avoiding having to copy the response from one region in memory to another region in memory, run it through some filters, and then copy it again. It only does this for small responses.

Lastly, I really dislike the common method of benchmarking you ran ab 1,10,….

So basically what your really testing is how does Nginx scale as traffic increases from low to high. Nginx default configuration is to run many many more processes/threads then Apache does. So in Apache you go: 1 concurrent, 5 concurrent, 10 concurrent – opps Apache has to start up another 10 threads, 15 concurrent, 20 concurrent – opps time to start another 10 threads. That is why if you look at the raw data you see these really weird sudden drops in performance as concurrency crosses the new thread boundary.

Run it in the opposite direction and you will see an initial high performance for nginx[ramps up faster to 10,000 concurrent] but then as you go down the charts start to differ..nginx is more aggressive about cleanup/killing extra threads. Try varying back and forth, 10,000 to 5000, to 8000, to 500, to 3000 Of course this will not be a nice chart – but it will be real world.

Gwan has some interesting benchmarking tools and a different metric. I don’t agree with the author on some of his choices[he’s still using small files and sequential ramp up] but his tools do a better job of tracking memory.