Why Nginx is better than Apache

Nginx has taken over the majority of the Web server market in just a few years. As we all know, Nginx is significantly more efficient than Httpd in processing large concurrent static requests, and can even easily solve the C10K problem.

In the case of high concurrent connections, Nginx is a good alternative to Apache server. Nginx can also be used as a layer 7 load balancing server. According to my test results, Nginx + PHP (FastCGI) can handle more than 30,000 concurrent connections, which is 10 times that of Apache under the same environment.

Generally speaking, a server with 4GB of memory + Apache (prefork mode) can only handle 3,000 concurrent connections, because they will occupy more than 3GB of memory and 1GB of memory must be reserved for the system. I once had two Apache servers. Because the MaxClients setting in the configuration file was 4000, when the number of concurrent Apache connections reached 3800, the server memory and swap space were full and crashed.

With 30,000 concurrent connections, this Nginx + PHP (FastCGI) server consumes 150M of memory ( 15M*10=150M ) for the 10 Nginx processes opened, and 1280M of memory ( 20M*64=1280M ) for the 64 php-cgi processes opened. Together with the memory consumed by the system itself, the total memory consumed is less than 2GB. If the server memory is small, you can just start 25 php-cgi processes, so that the total memory consumed by php-cgi is only 500M.

With 30,000 concurrent connections, PHP programs accessing the Nginx+ PHP (FastCGI) server are still very fast.

Why Nginx is better than httpd in handling high concurrency? Let's start with the working principles and working modes of the two web servers.

1. Three working modes of Apache

We all know that Apache has three working modules: prefork, worker, and event.

• prefork: Multiple processes, each request is responded by a process, and this process will use the select mechanism to notify.
• Worker: Multithreading, a process can generate multiple threads, each thread responds to one request, but the notification mechanism still selects but can accept more requests. event: Based on the asynchronous I/O model, one process or thread, each process or thread responds to multiple user requests, it is implemented based on event-driven (that is, epoll mechanism).

1. Working principle of prefork

If you do not explicitly specify an MPM with "--with-mpm", prefork is the default MPM on the Unix platform. The pre-forked child process method it uses is also the model used in Apache1.3.

Prefork itself does not use threads. Version 2.0 uses it to maintain compatibility with version 1.3. On the other hand, prefork uses separate child processes to handle different requests, and the processes are independent of each other, which also makes it one of the most stable MPMs.

2. Working principle of worker

Compared with prefork, worker is a brand new MPM in version 2.0 that supports a hybrid model of multi-threading and multi-process. Because threads are used for processing, a relatively large number of requests can be processed, and the overhead of system resources is less than that of process-based servers.

However, the worker also uses multiple processes, and each process generates multiple threads to obtain the stability of the process-based server. This MPM working mode will be the development trend of Apache2.0.

3. Event-based features

A process responds to multiple user requests and uses the callback mechanism to reuse the socket. After the request comes in, the process does not process the request, but directly hands it over to other mechanisms for processing, and uses the epoll mechanism to notify whether the request is completed. In this process, the process itself is always in an idle state and can continue to receive user requests. A process can respond to multiple user requests. Supports massive concurrent connections and consumes fewer resources.

2. How to improve the concurrent connection processing capability of the Web server

There are several basic conditions:

1. Thread-based, that is, one process generates multiple threads, and each thread responds to each request from the user.

2. Event-based model, a process handles multiple requests and notifies the user of request completion through the epoll mechanism.

3. Disk-based AIO (Asynchronous I/O)

4. Support mmap memory mapping. When a traditional web server inputs a page, it first inputs the disk page into the kernel cache, and then copies a copy from the kernel cache to the web server. The mmap mechanism is to map the kernel cache to the disk, and the web server can directly copy the page content. There is no need to first import the pages on disk into the kernel cache.

As it happens, Nginx supports all of the above features. Therefore, the statement on the Nginx official website that Nginx supports 50,000 concurrent connections is well-founded.

3. The excellence of Nginx

Traditionally, Web services based on process or thread model architecture handle concurrent connection requests through each process or each thread, which is bound to cause blocking during network and I/O operations. Another inevitable result is low utilization of memory or CPU.

Generating a new process/thread requires preparing its runtime environment in advance, which includes allocating heap memory and stack memory for it, and creating a new execution context for it. These operations require CPU usage, and too many processes/threads will cause thread jitter or frequent context switching, further degrading system performance.

Another high-performance web server/web server reverse proxy: Nginx. The main focus of Nginx is its high performance and high-density utilization of physical computing resources, so it adopts a different architectural model. Inspired by the advanced "event"-based processing mechanisms in the design of various operating systems, Nginx adopts a modular, event-driven, asynchronous, single-threaded, and non-blocking architecture, and makes extensive use of multiplexing and event notification mechanisms.

In Nginx, connection requests are handled by a small number of Worker processes that contain only one thread using an efficient run-loop mechanism, and each Worker can handle thousands of concurrent connections and requests in parallel.

4. How Nginx works

Nginx runs multiple processes simultaneously as needed: a master process and several worker processes. When caching is configured, there will also be cache loader processes and cache manager processes. All processes contain only one thread, and inter-process communication is mainly achieved through the "shared memory" mechanism. The main process runs as root, while workers, cache loaders, and cache managers should all run as unprivileged users.

In the case of high connection concurrency, Nginx is a good alternative to Apache server.

Nginx is very easy to install, the configuration file is very concise (it also supports perl syntax), and there are very few bugs in the server: Nginx is very easy to start, and can run almost 7*24 non-stop, and does not need to be restarted even if it runs for several months. You can also upgrade the software version without interrupting the service.

5. The birth of Nginx mainly solves the C10K problem

Finally, we analyze from the perspective of the multiplexed IO model used by each:

1. Select model: (used by Apache, but not often used due to restrictions such as modules);

There is a maximum limit on the number of file descriptors that a single process can monitor;

The data structure maintained by select() stores a large number of file descriptors. As the number of file descriptors increases, the overhead caused by copying the address space between user mode and kernel will also increase linearly;

Due to the delay in network response time, a large number of TCP connections are inactive, but calling select() will still perform a linear scan on all sockets, which will cause certain overhead;

2. poll: poll is a re-implementation of select by Unix. The only problem it solves is that poll has no limit on the maximum number of file descriptors.

3. epoll model: (used by Nginx)

Epoll brings two advantages, greatly improving performance:

1) Based on the event-based ready notification method, select/poll method, the kernel will scan all monitored file descriptors only after the process calls a certain method, and the epoll event registers a file descriptor through epoll_ctl(). Once a file descriptor is ready, the kernel will use a callback mechanism similar to callback to quickly activate the file descriptor, and epoll_wait() will be notified

2) When you call epoll_wait() once to get a ready file descriptor, what is returned is not the actual descriptor, but a value representing the number of ready descriptors. These values ​​are taken to an array specified by epoll to obtain the corresponding number of file descriptors in turn. Memory mapping (mmap) technology is used here to avoid the overhead of copying a large number of file descriptors.

3) Of course, epoll also has certain limitations. epoll is only implemented in Linux 2.6, and other platforms do not have it. This is obviously contrary to the excellent cross-platform server such as Apache.

4) Simply put, epoll is an upgraded version of select, and there is no maximum limit on the file descriptors managed by a single process. But epoll is only available on the Linux platform. As a cross-platform Apache is not used

Source: http://codebay.cn/post/8557.html

This concludes this article on why Nginx is better than Apache. For more information about Nginx vs. Apache, please search 123WORDPRESS.COM’s previous articles or continue browsing the following related articles. I hope you will support 123WORDPRESS.COM in the future!