Nginx vs Apache compared

Introduction: Why Is Choosing Between Nginx or Apache Important?

When it comes to setting up a serious website, the first technical decision you have to make is choosing the web server. In most cases, the discussion boils down to two main options: Nginx and Apache. Both have been covering about 60 to 70 percent of the world's websites together for years, but their architecture and design philosophy are completely different.

If you are migrating to a new server, or you want to build a website that is going to handle high traffic, choosing between Nginx or Apache can make a significant difference in resource consumption, response speed, and even server management complexity. In this article, without bias toward either, we will examine the architecture, performance, and use cases of both, and finally show you how you can benefit from both simultaneously.

Request Processing Architecture: The Fundamental Difference Between Nginx or Apache

The most important difference between Nginx or Apache comes down to how they manage connections and process requests. This architectural difference is the root of all other performance differences.

Apache: Process-based Model

Apache was originally designed based on the one connection, one process model. Each HTTP request that reaches the server gets a separate process, or in newer versions, a separate thread. This model was very simple and reliable in the early days of the web, but it has an inherent problem: each process consumes a certain amount of RAM.

For example, if each Apache process consumes an average of 50 MB of RAM and you have 1000 concurrent connections, you will need 50 GB of RAM. This means that under high load, Apache quickly devours server resources.

Of course, Apache has tried to solve this problem by introducing the mpm_event and mpm_worker modules. In mpm_event mode, keep-alive connections are transferred to separate threads, and only real requests consume threads. But even with this optimization, memory consumption and concurrency management still do not match Nginx.

Nginx: Event-driven Model

Nginx is designed with a completely different architecture: event-driven and asynchronous. Instead of creating a process for each connection, Nginx uses an event loop that can manage tens of thousands of connections with one or a few worker processes.

Each Nginx worker process can simultaneously respond to thousands of connections without creating a separate thread or process for each one. This means memory consumption remains almost constant, even when the number of concurrent connections increases from 100 to 10,000.

To understand better, imagine you have a restaurant. Apache is like a restaurant that hires a dedicated waiter for each customer. Nginx is like a restaurant that has one agile waiter who can serve 100 customers at the same time. Under normal conditions, both work, but when the restaurant gets crowded, the second model is clearly more efficient.

Performance Under High Load: The Real Test of Nginx or Apache

Let's examine this architectural difference in a real-world scenario. Suppose you have a news website that 5000 users visit simultaneously at one moment.

Resource Consumption Under High Load

With Apache in the default mpm_prefork mode, you need 5000 processes. If each process consumes 30 MB of RAM, you will need a total of 150 GB of RAM. This number is unacceptable for most virtual or dedicated servers.

With Nginx, you can manage the same 5000 connections with 4 worker processes (usually equal to the number of CPU cores) and about 200 MB of total RAM. This means Nginx can easily handle 5000 connections on hardware where Apache can barely manage 500 connections.

In practice, benchmark tests show that Nginx can process 2 to 3 times more requests per second (RPS) than Apache with the same hardware, especially when it comes to static files.

Static File Serving Comparison

One of Nginx's main strengths is serving static files (images, CSS, JavaScript). Nginx uses the sendfile mechanism in the Linux kernel to transfer files directly from disk to the network socket, without data passing through user space. This means CPU overhead is almost zero.

Apache, to serve a static file, must read the data from disk, transfer it to memory, and then send it to the socket. This multi-step process consumes more CPU and memory.

In a simple test using the ab (ApacheBench) tool on a 10 KB file:

ab -n 10000 -c 100 http://your-server.com/test.jpg

Results typically show that Nginx responds to about 15,000 to 20,000 requests per second, while Apache reaches 5,000 to 8,000 requests per second on the same hardware.

Flexibility and Compatibility: Apache's Strong Point

Despite Nginx's performance advantage, Apache still leads in some areas. Apache's most important advantage is configuration flexibility and compatibility with a wide range of modules.

.htaccess Files

Apache allows you to place configuration settings in .htaccess files in any directory. This feature is crucial for shared hosting and users who do not have access to the main server configuration. You can apply rewrite rules, access restrictions, and cache settings without accessing the main configuration file.

Nginx does not support .htaccess by default. All configurations must be done in the main configuration file (usually /etc/nginx/sites-available/). This means that to change settings, you need SSH access to the server and must restart the service after each change.

If your website uses WordPress or Joomla and depends on plugins that modify .htaccess rules, Apache is the simpler choice. But if you have full control over the server, this Nginx limitation is not very important.

CGI Support and Legacy Modules

Apache has deep compatibility with modules like mod_php, mod_perl, and mod_python. If your application depends on these modules, migrating to Nginx will require rewriting part of the code or using alternative solutions (such as PHP-FPM).

Apache also natively supports CGI, while Nginx does not support CGI by default and you must use FastCGI. This is a serious obstacle for legacy applications that only understand CGI.

Combining Nginx or Apache: The Best of Both Worlds

A common question is: "Should I choose one, or can I use both?" The short answer: Yes, you can, and this combination is common in many professional infrastructures.

Reverse Proxy Architecture

In this architecture, Nginx acts as the front-end server and receives all HTTP requests. It then serves static file requests itself and forwards dynamic requests to Apache, which runs in the back-end.

This combination offers the benefits of both:

• Nginx serves static files with high performance and protects the server against DoS attacks.
• Apache runs dynamic applications and WordPress with all required modules thanks to its flexibility.
• .htaccess settings still work because dynamic requests reach Apache.

Sample Configuration

Suppose Nginx runs on port 80 and Apache runs on port 8080. The Nginx configuration for forwarding PHP requests to Apache looks like this:

server {
    listen 80;
    server_name example.com;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location ~* \.(jpg|jpeg|png|gif|css|js|ico)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

In this configuration, static file requests (images, CSS, JS) are served directly by Nginx with a 30-day cache. PHP requests are forwarded to Apache on port 8080, and Apache processes them using mod_php or PHP-FPM.

Important Configuration Note

A common mistake in this architecture is forgetting to set proxy_set_header. If you do not send these headers, Apache will not see the user's real IP address, and all requests will appear to come from 127.0.0.1. This makes Apache logs useless and breaks WordPress security plugins that work based on IP.

You should also enable Listen 8080 in the Apache configuration and make sure Apache only listens on localhost:

Listen 127.0.0.1:8080

This prevents direct user access to Apache and increases security.

Common Mistakes in Choosing Nginx or Apache

In this section, we point out a few common mistakes we have seen a lot in real projects.

Choosing Based on Hype, Not Need

Many people choose Nginx just because it is "more modern," or Apache because "everyone uses it." This way of thinking is wrong. If your website is a personal blog with 100 visits per day, the performance difference between Nginx or Apache is completely meaningless to you. In this case, the ease of using .htaccess in Apache might be a better choice.

Ignoring Keep-Alive Settings

In Nginx, the keepalive_timeout setting defaults to 75 seconds. If you set this value too high, many idle connections will be held, and you may hit the connection limit. A reasonable value between 10 and 30 seconds is suitable for most websites.

In Apache, the KeepAliveTimeout defaults to 5 seconds, which is suitable for most cases, but if your website uses WebSocket, you should increase this value.

Forgetting SSL and HTTP/2

Both servers support SSL and HTTP/2, but their configuration methods differ. In Nginx, SSL configuration is very simple:

listen 443 ssl http2;
ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;

In Apache, you need to enable the mod_ssl module and perform similar configuration. If you are not using HTTP/2, you will see a noticeable difference in page load speed under high load, especially for websites with many CSS and JS files.

Conclusion: Which One Should You Choose?

The choice between Nginx or Apache depends on your specific needs, not popularity or hype. If your website has high traffic, uses many static files, or you want to minimize resource consumption, Nginx is the better choice. If you depend on .htaccess, use legacy Apache modules, or are on shared hosting that only supports Apache, Apache is the more suitable option.

In many cases, the best solution is to combine both: Nginx in front for serving static files and managing connections, and Apache in the back for processing dynamic code. This architecture is very common in professional infrastructures and offers the benefits of both servers in one.

If you are setting up a new server and need technical consultation, the ServerNet support team can guide you in choosing the best architecture for your website. The important thing is to make your decision based on the real needs of your project, not market hype.