Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Apache vs Nginx are compared performance wise since Apache is based on threads (for each new connection a new thread) and nginx is based on process (for each new connection to the server a new process). So Nginx perform better since process based. But if they are deployed on Linux does it matter since there is no direct concept of threads and in Linux threads are mapped to process at kernel level. So performance should be same for Apache and Nginx on Linux but Nginx is better then Apache, why?

share|improve this question

migrated from May 4 '11 at 9:37

This question came from our site for professional and enthusiast programmers.

"better" is a loaded term. There are plenty of sites (e.g. disqus) that run their apps with a front facing nginx server and use multiple apache + mod_wsgi instances to actually serve their application. Are you seeing an performance problems with Apache because of which you need to switch web servers or is this purely out of curiosity? – Noufal Ibrahim May 4 '11 at 7:30
Also, Apache can be configured in different ways (single process - multi threaded, multi process etc.). As far as I know, Nginx asynchronously handles the connections rather than relying on multiple processes/threads. – Noufal Ibrahim May 4 '11 at 7:31

First of all it is not true that process forking is generally more efficient than threading. This hugely depends on how the OS kernel handles threads/processes.

It is well known that forking processes is an easy, efficient task on Unix systems, but terrible on Windows. Which means that on Windows you're probably much better off using threads, while on Unix this does not necessarily mean that threads are more or less efficient than processes.

Apache 2.X allows to be run in several modes, including spawning processes or working with a thread pool.

There are many ressources on the web which benchmark nginx against apache. The use of each benchmark is limited due to different testing scenarios:

  • Configuration of the server, esp. the apache server
  • Workload to be covered, static vs dynamic content, etc.
  • Benchmark interest: Overall throughput, response times, variation in response times

The best option left for you is to design your own benchmark on your server, with your scenario. See also this question: How to benchmark apache/nginx setup

share|improve this answer
+1. Useful answer to a rather vague question. – Noufal Ibrahim May 4 '11 at 7:53

You probably don't care much.

Anecdotal evidence suggests that Nginx is more memory efficient when there are a lot of connected clients which aren't doing very much (think of keep-alives, slow requests etc). This means that it can handle a lot more idle connections in the same machine, which is useful in some kinds of web server.

So if all your clients are super-fast, super-busy and on low-latency links (think of a highly artifical load-test system) then Apache might do quite well. But put a real internet and real clients into the mix, and you'll see the advantages of Nginx.

Nginx does not reserve a thread or a process for each connected client - it handles them asynchronously, which dramatically reduces the overhead that idle clients produce.

share|improve this answer

nginx is based on process (for each new connection to the server a new process)

This is not correct. Nginx does spawn a number of worker processes to handle requests, but each one can handle more than one request at once as it is event-driven. This is the source of a lot of its advantages over Apache, as it can handle a huge number of concurrent requests with a relatively modest number of processes.

As for performance, that depends entirely on the situation; neither tool is better in all circumstances.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.