Comparison of the three request processing modes (MPM) in Http
http supports three MPM working modes:
- prefork ,
- worker,
- enent
prefork --- multi-process I/O model, each process responds to a request
Prefork MPM: Prefork MPM: There is a main control process, and then multiple child processes are generated. Each child process has an independent thread to respond to user requests. It takes up memory relatively, but it is relatively stable. You can set the maximum and minimum number of processes, which is the most An ancient mode, and the most stable mode, suitable for scenes where the traffic is not very large
- Advantages: stable
- Disadvantages: slow, take up resources, not suitable for high concurrency scenarios
This multiprocessing module (MPM) implements a non-threaded, pre-forked web server. Each server process can respond to incoming requests, and the parent process manages the size of the server pool. It is suitable for sites that need to avoid threading in order to be compatible with non-thread-safe libraries. It is also the best MPM to isolate each request, so the problem of a single request will not affect any other requests. This MPM has a strong self-regulation ability, so it is rarely necessary to adjust its configuration instructions. The most important thing is that MaxRequestWorkers is large enough to handle all the concurrent requests you wish to receive, but small enough to ensure that all processes have enough physical RAM.
Configuration related to prefork mode:
StartServers 100 #记录开始进程为100 当没有人访问的时候就变成为80个
MinSpareServers 50
MaxSpareServers 80
ServerLimit 2560 #最多进程数,最大值 20000
MaxRequestWorkers 2560 #最大的并发连接数，默认256
MaxConnectionsPerChild 4000 #子进程最多能处理的请求数量。在处理MaxRequestsPerChild 个
请求之后,子进程将会被父进程终止，这时候子进程占用的内存就会释放(为0时永远不释放）
MaxRequestsPerChild 4000 #从 httpd.2.3.9开始被MaxConnectionsPerChild代替worker ---multiplexed multi-process I/O model, multi-process multi-thread
* A main process: generate m child processes, each child process is responsible for generating n threads, each thread responds to a request, and concurrently responds to the request: m n**
It is a mixed multi-process and multi-threaded model . There is a control process that starts multiple sub-processes. Each sub-process contains a fixed thread. The thread process is used to process the request. When the thread is not enough, it will start a new one. The child process, and then start the thread in the process to process the request, because it uses the thread to process the request, it can withstand higher concurrency.
- Advantages: Compared with prefork, it occupies less memory and can handle more requests at the same time
- Disadvantages: using the keep-alive long connection method, a thread will always be occupied, even if there is no data transmission, it needs to wait until the timeout will be released. If too many threads are occupied in this way, it will also lead to unavailable service threads in high concurrency scenarios. (This problem also occurs in prefork mode)
Configuration related to worker and event modes
ServerLimit 16 #最多worker进程数 Upper limit on configurable number of
processes
StartServers 10 #Number of child server processes created at startup
MaxRequestWorkers 150 #Maximum number of connections that will be processed
simultaneously
MinSpareThreads 25 #每个work 最多空闲25个 最大空闲75个
MaxSpareThreads 75
ThreadsPerChild 25 #Number of threads created by each child process每个线程 i控制的个数event --- event-driven model, adding a listener thread
A main process : spawn m child processes, each child process is responsible for spawning n threads, each thread responds to a request and responds concurrently
Request: m*n, there is a special monitoring thread to manage these keep-alive type threads . When there is a real request, the request is passed to the service thread, and after the execution is completed, the release is allowed. This enhances the request processing capability in high concurrency scenarios
event MPM: The latest mode in Apache belongs to the event-driven model (epoll). Each process responds to multiple requests. In the current version, it is already a stable and usable mode. It is very similar to the worker mode. The biggest difference is that it solves the problem of wasting resources of threads that have been occupied for a long time in the keep-alive scenario. (Some threads are kept waiting because they are kept empty. There are almost no requests in the middle. Come over and even wait until the timeout). In event MPM, there will be a dedicated thread to manage these keep-alive threads. When a real request comes, the request is passed to the service thread, and after the execution is completed, it is allowed to be released. This enhances the request processing capability in high concurrency scenarios
The event only starts to establish a connection when there is data to send, the connection request will trigger the worker thread, that is, an option of TCP is used, called delayed acceptance of the connection TCP_DEFER_ACCEPT, after adding this option, if the client only makes a TCP connection, it will not Sending a request will not trigger the Accept operation, and will not trigger the worker thread to work, and a simple anti-*** (TCP connection)
Advantages: Single thread responds to multiple requests, occupies less memory, and performs better under high concurrency. There will be a dedicated thread to manage keep-alive threads. When a real request comes, the request is passed to the service thread. After the execution is complete, it is allowed to release the
disadvantages: no thread safety control
to sum up:
Sites that require higher scalability can choose to use threaded MPM, that is, workers or events (Internet companies) that
require reliability or sites that are compatible with old software can use prefork (traditional companies).
Configuration related to worker and event modes
ServerLimit 16 #最多worker进程数 Upper limit on configurable number of
processes
StartServers 10 #Number of child server processes created at startup
MaxRequestWorkers 150 #Maximum number of connections that will be processed
simultaneously
MinSpareThreads 25 #每个work 最多空闲25个 最大空闲75个
MaxSpareThreads 75 #每个线程 i控制的个数
ThreadsPerChild 25 #Number of threads created by each child processSwitch the MPM used
#启用要启用的MPM相关的LoadModule指令即可，其它未启用的两项需要在行首加#注释
#三种选择一种就可以的
vim /etc/httpd/conf.modules.d/00-mpm.conf
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
LoadModule mpm_event_module modules/mod_mpm_event.soNote: Do not enable multiple MPM modules at the same time, otherwise the following error will occur
AH00534: httpd: Configuration error: More than one MPM loaded.Example: View the default MPM working mode of CentOS 8 and CentOS 7
#查看CentOS 8 默认的MPM工作模式
[root@centos8 ~]#httpd -M |grep mpm
AH00558: httpd: Could not reliably determine the server's fully qualified domain
name, using centos8.localdomain. Set the 'ServerName' directive globally to
suppress this message
mpm_event_module (shared)
#查看CentOS 7 默认的MPM工作模式
[root@centos7 ~]#httpd -M |grep mpm
AH00558: httpd: Could not reliably determine the server's fully qualified domain
name, using centos7.localdomain. Set the 'ServerName' directive globally to
suppress this message
mpm_prefork_module (shared)Example: Modify CentOS 8 to use prefork model
[root@centos8 ~]#vim /etc/httpd/conf.modules.d/00-mpm.conf
[root@centos8 ~]#grep Load /etc/httpd/conf.modules.d/00-mpm.conf
# one of the following LoadModule lines. See the httpd.conf(5) man
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
#LoadModule mpm_event_module modules/mod_mpm_event.so
[root@centos8 ~]#httpd -M | grep mpm
AH00558: httpd: Could not reliably determine the server's fully qualified domain
name, using centos8.localdomain. Set the 'ServerName' directive globally to
suppress this message
mpm_prefork_module (shared)Part of the content comes from https://www.cnblogs.com/luck-pig/p/12007045.html