This article will be explained in a table-by-table manner! First give the advantages and disadvantages of Nginx and Apache, and then analyze the reasons from the architecture and mode
Advantages and disadvantages analysis
1.
Advantages
of Nginx : 1. Nginx has good concurrency. Nginx uses epoll as the event-driven model in Linux. The way of processing requests is asynchronous and non-blocking. The load capacity is much higher than Apache, and Apache is blocking In the case of high concurrency, Nginx can easily maintain low resource consumption and high performance, and Apache is prone to spike in the number of processes when PHP processing is slow or the front-end pressure is high, thus denying service
2. The performance of nginx for processing static files is better than that of Apache
3. Nginx involves a high degree of modularity, writing modules is relatively simple
4. The nginx configuration is concise, you can use -t to test the configuration after the configuration is complete.
5. Nginx can be used as a load balancer, supporting 7-layer load
6. nginx itself is a reverse proxy server, and can be used as a very good mail proxy server
7.nginx can realize hot restart
Disadvantages:
1. Nginx's ability to process dynamic files, that is, interact with the back-end PHP server is average, and Apache is very efficient in handling dynamic requests
About the detailed degradation of nginx, you can refer to another article of the author to get an initial understanding of Nginx
II. Apache
advantages:
1. Apache rewrite is stronger than Nginx. In the case of frequent rewrite, use Apache
2. Because Apache appears longer than Nginx, he may have fewer bugs and be more stable
3. Apache's PHP support is relatively simple, because PHP was even a module in the Apache architecture, and Nginx needs to be used with other backends (such as FastCGI)
4. Apache's ability to handle dynamic requests is relatively strong, nginx is not doing well in this regard
Disadvantages:
1. Apache is more bulky than nginx, and its ability to cope with high concurrency is weaker than nginx
3. Summary
The advantages and disadvantages of Nginx and Apache are shown in the form of a table for your comparison.
| comparisons | nginx | apache |
|---|---|---|
| Ability to cope with high concurrency | Strong | general |
| Ability to handle static requests | Strong | general |
| Ability to handle dynamic requests | general | Strong |
| stability | general | Strong |
| extensions | less | many |
| Resource utilization (performance) | better | general |
| Multi-core CPU support | Good effect | General effect |
The difference between static webpage and dynamic webpage Please read this article The difference between static webpage and dynamic webpage
Architecture analysis
We mainly analyze the architecture of Nginx and Apache on high concurrency and performance! ! !
The difference between Nginx and Apache is mainly because the working mode of Nginx is asynchronous and non-blocking, while the working mode of Apache is synchronously blocking
Concurrency related implementation
1. Working mode (method of processing Web requests, synchronous or asynchronous)
1.
The implementation of the working mode of Nginx ----- asynchronous nginx is to first create a master process by ngxin, and then create a worker process by the master process. and the effect is to create a child process stops, and the user's request to the worker process, i.e., the actual processing worker process is requested by the user, since it is asynchronous communication mode of the structure, so that a worker process can handle multiple user requests
2 .Apache ----- Synchronous
Aapache has several working modes, but its network communication methods are synchronous communication, that is, each process or thread can only handle one user's request , similar to nginx, Apache is also composed of a The main process control generates many worker processes (there can be many worker threads under the worker process), the main process load creates child processes and schedules user requests, and it is the worker process (or worker thread) that is actually responsible for processing user requests
Here are three working modes of Apache, which are schematic diagrams of prefork mode, worker mode and event mode, which are all synchronous communication mode, that is, each process or thread can only process one user's request at the same time! However, each mode has its corresponding usage scenario, so I will not repeat it here.
After comparing the web request methods, we can generally get why Nginx is better than Apache. Let me summarize my view
Because each worker process of Nginx can handle requests from multiple users, the number of Nginx process switching will be very few, and thus the context switching will be less, so that the system consumes less resources. And Apache needs to switch processes frequently, so the resources consumed by process switching hinder the performance improvement. Secondly, when faced with high concurrency, Apache needs to create multiple processes or threads. Creating processes and threads also consumes system resources, so when faced with high concurrency, nginx can easily face it, while Apache faces high concurrency. difficult
Performance-related implementation
Two. Event-driven model (call local process to handle I / O mode, blocking or non-blocking) to
undertake the above-mentioned way of processing Web requests, when the server receives the Web request, the main process will dispatch the request and assign it to the corresponding worker process. At this point the worker process starts to process web requests. If the user requests content in a file, the worker process will perform I / O operations.
When it comes to I / O operations, let's briefly mention here, blocking and non-blocking. First of all, the blocking we are talking about here is blocking for I / O operations
: when a process calls an I / O operation, he needs to wait until the I / O operation completes the returned result. If he does nothing during the waiting period Do, just wait for the completion of the I / O operation, then it is said to be a blocking process
non-blocking: When a process calls the I / O operation, he does not need to wait for the completion of the I / O operation to return and can immediately process other Thing, this is a non-blocking process
Correspondingly, Nginx's I / O is non-blocking, and Apache's I / O is blocking
Let me briefly talk about my views.
Non-blocking always works with asynchronous (Nginx), and blocking always works with synchronous (Apache).
Because Nginx communicates asynchronously, its non-blocking I / O is meaningful (because asynchronous can handle multiple requests at the same time, when a requested I / O operation is performed, the worker process can process other requests ).
Because Apache communicates synchronously, his non-blocking I / O is meaningless (because of synchronization, a process can only process one Web request, and when the requested I / O operation is performed, the process has no other requests. Can handle)
Okay, after talking about the concepts of blocking and non-blocking, let ’s move on to our topical event-driven model
After we request an I / O operation, how do we know that the I / O request has been completed, and let's get the return result of the I / O? There are two ideas!
First, the worker process marks the I / O operations, and then periodically polls these marks. If the polled I / O operation has been completed, then our process will process the I / O, otherwise it will not be processed.
Second, the worker process no longer actively asks, but after the I / O operation is completed, in some way, the kernel informs the process that the I / O operation has been completed, and then the worker process processes the I / O operation.
Obviously, the efficiency of the second method will be higher, because traversing all I / O operations will undoubtedly waste system resources, especially when the amount of concurrency is large and there are many I / O operations. Is very large, then the response to user requests will be slow, that is, the performance will decrease
Back to our Nginx and Apache, Apache uses the first model, the typical representative is called the select model, and Nginx uses the second model, the implementation on Linnux is the epoll model
Below, let's briefly introduce some select and epoll models
select library
The steps to use the select library are:
first, create a descriptor set for the event of interest (specific file for I / O operations). For a descriptor, you can pay attention to the read (read) event, write (write) event and exception (Exception) event, so you need to create three types of event descriptor sets, which are used to collect the descriptors of read events, write The descriptor of the event and the descriptor of the abnormal event
call the underlying select () function and wait for the event to occur. Then poll each event descriptor of all event descriptor collections, check whether there is a corresponding event, and process it if there is
Create a descriptor set for each I / O request, which contains three types, and then traverse these sets regularly, and return the call result to the work-process process once I / O is completed
epoll library The
epoll library is one of the high-performance event-driven libraries supported by the Nginx server. The efficiency of the epoll library is very high
The select library and polo library are all processed by creating a list of pending events, and then sending this list to the kernel. When returning, check the list by polling to determine whether an event has occurred. In this way, when there are many descriptors, the efficiency becomes very low .
A better practice is to leave the management of the descriptor list to the kernel. Once something happens, the kernel notifies the process of the descriptor list of the event, which avoids polling the entire descriptor list. Epoll The library is such a model
First, the epoll library informs the kernel to create an event list with N descriptors through relevant calls. Then, set the events of interest to these descriptors and add it to the kernel's event list. You can also modify and delete the descriptors in the event list through related calls
After the setting is completed, the epoll library starts to wait for the kernel to notify that an event has occurred. After an event occurs, the kernel reports the descriptor list of the event to the epoll library. Get the epoll library of the event list, and you can process the event
The epoll library is efficient on the Linux platform. It supports a process to open a large number of event descriptors. The upper limit is the maximum number of files that the system can open. At the same time, the I / O efficiency of the epoll library does not decrease linearly with the increase in the number of descriptors. It will only operate on the "active" descriptors reported by the kernel
Through the analysis of the event processing model, we can find out why Nginx's performance is better than Apache's
because the epoll model used by Nginx is more efficient when processing requests, especially in high concurrency environments. Its advantages are more prominent Because the select model of Apache needs to traverse file descriptors, when the concurrency is large, the time and consumption of traversing are relatively large, which will cause performance loss, and the epoll model is different. In the case of high concurrency, it is still caused by The kernel notifies the worker process of the completion of I / O, and does not go through it. It only informs the worker process when it is completed, so the performance of nginx under high concurrency will not have much impact, and Apache is under high concurrency. Performance will be greatly reduced
