Why is Nginx more awesome than Apache

  • 2021-10-16 05:29:06
  • OfStack

Nginx has won the Web server in just a few years. As we all know, Nginx is obviously more efficient than Httpd in handling large concurrent static requests, and can even easily solve the problem of C10K.

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

Generally speaking, servers with 4GB memory + Apache (prefork mode) 1 can only handle 3000 concurrent connections, because they will occupy more than 3GB of memory and have to reserve 1GB of memory for the system. I used to have two Apache servers, because MaxClients was set to 4000 in the configuration file. When the number of Apache concurrent connections reached 3800, the server memory and Swap space were full and crashed.

This Nginx + PHP (FastCGI) server consumes 150M memory for 10 Nginx processes under 30,000 concurrent connections ( 15M*10=150M ), the 64 php-cgi processes that are open consume 1280M memory ( 20M*64=1280M ), plus the memory consumed by the system itself, consumes less than 2GB in total. If the server memory is small, only 25 php-cgi processes can be started, so that the total memory consumed by php-cgi is only 500M.

With 30,000 concurrent connections, the PHP program accessing the Nginx + PHP (FastCGI) server is still fast.

Why Nginx is better than httpd in dealing with high concurrency, let's start with the working principle and working mode of two web servers.

1. Three working modes of Apache

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

prefork: Multi-process, each request with 1 process response, this process will use the select mechanism to notify. worker: Multithreaded, one process can generate multiple threads, each thread responds to one request, but the notification mechanism is still select, but it can accept more requests. event: Based on the asynchronous I/O model, one process or thread, each responding to multiple user requests, is event-driven (that is, the epoll mechanism).

1. Working principle of prefork

If you do not explicitly specify an MPM using "with-mpm", prefork is the default MPM on the Unix platform. The pre-derived child process mode adopted by it is also the mode adopted in Apache 1.3.

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

2. Working principle of worker

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

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

3. Event-based features of event

One process responds to multiple user requests, and uses callback mechanism to reuse sockets. After the request comes over, the process does not process the request, but directly handles it to other mechanisms, and notifies whether the request is completed through epoll mechanism; In this process, the process itself is in an idle state and can receive user requests directly. One process can respond to multiple user requests. Support a large number of concurrent connections and consume less resources.

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

There are several basic conditions:

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

2. Event-based model, one process handles multiple requests, and notifies users of the completion of requests through epoll mechanism.

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

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

As it happens, Nginx supports all the above features. Therefore, Nginx official website says that Nginx supports 50000 concurrency, which is based on it.

3. The excellence of Nginx

Traditionally, Web services based on process or thread model architecture process concurrent connection requests per process or per thread, which will inevitably lead to blocking in network and I/O operations. Another inevitable result is low utilization rate of memory or CPU.

To generate a new process/thread, it is necessary to prepare its runtime environment in advance, which includes allocating heap memory and stack memory, creating a new execution context for it, etc. All these operations require CPU, and too many processes/threads will also lead to thread jitter or frequent context switching, which will further reduce system performance.

Another high-performance web server/Web server reverse proxy: Nginx, Nginx mainly focuses on its high performance and high-density utilization of physical computing resources, so it adopts different architecture models. Inspired by the advanced processing mechanism based on "events" in various operating system designs, Nginx adopts modular, event-driven, asynchronous, single-threaded and non-blocking architecture, and adopts a large number of multiplexing and event notification mechanisms.

In Nginx, connection requests are processed by a few processes Worker with only one thread in an efficient loop-back mechanism (run-loop), and each Worker can handle thousands of concurrent connections and requests in parallel.

4. How Nginx works

Nginx will run multiple processes simultaneously on demand: a main process (master) and several worker processes (worker). When the cache is configured, there will also be cache loader process (cache loader) and cache manager process (cache manager), etc. All processes contain only one thread, and mainly realize inter-process communication through the mechanism of "shared memory". The main process runs as an root user, while worker, cache, loader, and cache, manager should all run as unprivileged users.

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

Nginx installation is very simple, configuration files are very concise (and can support perl syntax), Bugs has very few servers: Nginx is extremely easy to start, and can run almost 7*24 without interruption, even if it runs for several months without restarting. You can also upgrade software versions without interruption.

5. The birth of Nginx mainly solves the problem of C10K

Finally, we analyze from the multiplexing IO model used by each:

1. select model: (apache is used, but it is not used much due to the limitation of 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. With the increase of the number of file descriptors, the overhead caused by replication in user mode and kernel address space will also increase linearly;

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

2. poll: poll is re-implemented once by unix using select. The only problem solved is that poll has no limit on the maximum number of file descriptors;

3. epoll model: (used by Nginx)

epoll brings two advantages, which greatly improve performance:

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

2) When calling epoll_wait () once to obtain the ready file descriptor, the return is not the actual descriptor, but a value representing the number of ready descriptors. Get these values and go to an array specified by epoll to obtain the corresponding number of file descriptors in turn. Here, memory mapping (mmap) technology is used to avoid the overhead caused by copying a large number of file descriptors

3) Of course, epoll also has certain limitations. epoll can only be implemented on Linux 2.6, but other platforms do not, which obviously runs counter to apache, an excellent cross-platform server.

4) Simply put, epoll is an upgraded version of select, and there is no maximum limit to the file descriptor managed by a single process. However, epoll is only available on the linux platform. Apache as a cross-platform is not used

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


Related articles: