Apache三种工作模式

Apache MPM模块配置与并发处理
本文围绕Apache服务器并发问题展开。先介绍多路处理模块MPM,包括不同操作系统默认的MPM模块,如Windows的mpm_winnt、Unix/Linux的mpm_prefork和mpm_worker等。接着说明如何启用和修改MPM模块配置文件,以调整最大并发连接数,还给出各模块参数配置建议。

前言:
项目100人同时访问,导致访问速度变慢,作为一个没有遇到过这种情况下的辕,在各种查阅资料后,先用删除日志更改日志输出的方法处理后(处理方法:修改Apache日志输出相关配置方法),暂时好缓,后来又出现变慢,在查阅各种博客后,发现一个处理并发的方法,小试身手,发现有所好转。总结一下,加深记忆。

多路处理模块MPM(Multi-Processing Module)介绍
作为Apache的核心模块它针对不同的操作系统提供了多个不同的MPM模块,例如:mpm_beos、mpm_event、mpm_netware、mpmt_os2、mpm_prefork、mpm_winnt、mpm_worker。 如果条件允许,我们可以根据实际需求将指定的MPM模块编译进我们自己的Apache中(Apache的源码是开放的,允许用户自行编译)。不过,如果在编译时我们没有选择,Apache将按照如下表格根据不同的操作系统自行选择对应的MPM模块,这也是Apache针对不同平台推荐使用的MPM模块。

不同操作系统上默认的MPM模块
操作系统 MPM模块 描述
Windows mpm_winnt Windows系统
Unix/Linux mpm_winnt Unix/Linux系统
BeOS mpm_beos 由Be公司开发的一种多媒体操作系统,官方版已停止更新。
Netware mpm_netware 由NOVELL公司推出的一种网络操作系统
OS/2 mpmt_os2 一种最初由微软和IBM共同开发的操作系统,现由IBM单独开发(微软放弃OS/2,转而开发Windows)
mpm_event模块可以看作是mpm_worker模块的一个变种,不过其具有实验性质,一般不推荐使用。
当然,Apache在其官方网站上也提供了根据不同操作系统已经编译好对应MPM模块的成品Apache。你可以点击此处进入Apache官方网站下载。

此外,如果我们想要知道某个Apache内部使用的是何种MPM模块,我们可以以命令行的方式进入Apache安装目录\bin,然后键入命令httpd -l,即可查看到当前Apache内部使用的何种MPM模块。

由于在平常的开发工作中,BeOS、NetWare、OS/2等操作系统并不常见,这里我们主要针对Windows和Unix/Linux操作系统上的MPM模块进行讲解。在Windows和Unix/Linux操作系统上,MPM模块主要有mpm_winnt、mpm_prefork、mpm_worker三种。

mpm_prefork模块
mpm_prefork模块主要应用于Unix/Linux平台的Apache服务器,其主要工作方式是:当Apache服务器启动后,mpm_prefork模块会预先创建多个子进程(默认为5个),当接收到客户端的请求后,mpm_prefork模块再将请求转交给子进程处理,并且每个子进程同时只能用于处理单个请求。如果当前的请求数将超过预先创建的子进程数时,mpm_prefork模块就会创建新的子进程来处理额外的请求。Apache总是试图保持一些备用的或者是空闲的子进程用于迎接即将到来的请求。这样客户端的请求就不需要在接收后等候子进程的产生。

由于在mpm_prefork模块中,每个请求对应一个子进程,因此其占用的系统资源相对其他两种模块而言较多。不过mpm_prefork模块的优点在于它的每个子进程都会独立处理对应的单个请求,这样,如果其中一个请求出现问题就不会影响到其他请求。同时,mpm_prefork模块可以应用于不具备线程安全的第三方模块(比如PHP的非线程安全版本),且在不支持线程调试的平台上易于调试。此外,mpm_prefork模块还具有比mpm_worker模块更高的稳定性。

mpm_worker模块
mpm_worker模块也主要应用于Unix/Linux平台的Apache服务器,它可以看作是mpm_prefork模块的改进版。mpm_worker模块的工作方式与mpm_prefork模块类似。不过,由于处理相同请求的情况下,基于进程(例如mpm_prefork)比基于线程的处理方式占用的系统资源要多。因此,与mpm_prefork模块不同的是,mpm_worker模块会让每个子进程创建固定数量的服务线程和一个监听线程,并让每个服务线程来处理客户端的请求,监听线程用于监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用或是空闲的服务线程池。这样,客户端无须等待新线程或新进程的建立即可得到处理。

与mpm_prefork模块相比,mpm_worker模块可以进一步减少系统资源的开销。再加上它也使用了多进程,每个进程又有多个线程,因此它与完全基于线程的处理方式相比,又增加了一定的稳定性。

mpm_winnt模块
mpm_winnt模块是专门针对Windows操作系统而优化设计的MPM模块。它只创建一个单独的子进程,并在这个子进程中轮流产生多个线程来处理请求。

修改MPM模块配置
在对Apache的MPM模块具备一定了解后,我们就可以针对不同的MPM模块来修改Apache的最大并发连接数配置了。

启用MPM模块配置文件

在Apace安装目录/conf/extra目录中有一个名为httpd-mpm.conf的配置文件。该文件主要用于进行MPM模块的相关配置。不过,在默认情况下,Apache的MPM模块配置文件并没有启用。因此,我们需要在httpd.conf文件中启用该配置文件,如下所示:

Server-pool management (MPM specific)

Include conf/extra/httpd-mpm.conf (去掉该行前面的注释符号"#")

修改MPM模块配置文件中的相关配置

在启动MPM模块配置文件后,我们就可以使用文本编辑器打开该配置文件,我们可以看到,在该配置文件中有许多配置节点,如下图所示:
httpd-mpm.conf文件截图

此时,我们就需要根据当前Apache服务器所使用的MPM模块,来修改对应节点下的参数配置。首先,我们来看看mpm_winnt模块下的默认配置:

mpm_winnt模块
#由于mpm_winnt模块只会创建1个子进程,因此这里对单个子进程的参数设置就相当于对整个Apache的参数设置。

ThreadsPerChild 150 #推荐设置:小型网站=1000 中型网站=1000~2000 大型网站=2000~3500 MaxRequestsPerChild 0 #推荐设置:小=10000 中或大=20000~100000

对应的配置参数作用如下:

ThreadsPerChild:每个子进程的最大并发线程数。
MaxRequestsPerChild:每个子进程允许处理的请求总数。如果累计处理的请求数超过该值,该子进程将会结束(然后根据需要确定是否创建新的子进程),该值设为0表示不限制请求总数(子进程永不结束)。
该参数建议设为非零的值,可以带来以下两个好处:

  1. 可以防止程序中可能存在的内存泄漏无限进行下去,从而耗尽内存。
  2. 给进程一个有限寿命,从而有助于当服务器负载减轻的时候减少活动进程的数量。

注意:在以上涉及到统计请求数量的参数中,对于KeepAlive的连接,只有第一个请求会被计数。

接着,我们再来看看mpm_perfork模块和mpm_worker模块下的默认配置:

mpm_perfork模块

StartServers 5 #推荐设置:小=默认 中=20~50 大=50~100
MinSpareServers 5 #推荐设置:与StartServers保持一致
MaxSpareServers 10 #推荐设置:小=20 中=30~80 大=80~120
MaxClients 150 #推荐设置:小=500 中=500~1500 大型=1500~3000
MaxRequestsPerChild 0 #推荐设置:小=10000 中或大=10000~500000

此外,还需额外设置ServerLimit参数,该参数最好与MaxClients的值保持一致。

StartServers:  数量的服务器进程开始

MinSpareServers:  最小数量的服务器进程,保存备用

MaxSpareServers:  最大数量的服务器进程,保存备用

MaxRequestWorkers:  最大数量的服务器进程允许开始

MaxConnectionsPerChild:  最大连接数的一个服务器进程服务

prefork 控制进程在最初建立 “StartServers”个子进程后,为了满足MinSpareServers设置的需要创建一个进程,等待一秒钟,继续创建两 个,再等待一秒钟, 继续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足MinSpareServers设置的值为止。这种模式 可以不必在请求到 来时再产生新的进程,从而减小了系统开销以增加性能。MaxSpareServers设置了最大的空闲进程数,如果空闲进程数大于这个 值,Apache 会自动kill掉一些多余进程。这个值不要设得过大,但如果设的值比MinSpareServers小,Apache会自动把其调整 为 MinSpareServers+1。如果站点负载较大,可考虑同时加大MinSpareServers和MaxSpareServers。

MaxRequestsPerChild设置的是每个 子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild”个请求后将自 动销毁。0意味着无限,即子进程永不销毁。虽然缺省 设为0可以使每个子进程处理更多的请求,但如果设成非零值也有两点重要的好处:

可防止意外的内存泄 漏。
在服务器负载下降的时侯会自动减少子进程数。
因此,可根据服务器的负载来调整这个值。

MaxRequestWorkers指令集同时将服务请求的数量上的限制。任何连接尝试在MaxRequestWorkerslimit将通常被排队,最多若干基于上ListenBacklog指令。

在apache2.3.13以前的版本MaxRequestWorkers被称为MaxClients 。

MaxClients是这些指令中最为重要的一个,设定的是 Apache可以同 时处理的请求,是对Apache性能影响最大的参数。其缺省值150是远远不够的,如果请求总数已达到这个值(可通过 ps -ef|grep http|wc -l来确认),那么后面的请求就要排队,直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很 慢的主要原因。虽然理论上这个值越大,可以 处理的请求就越多,但Apache默认的限制不能大于256。

mpm_worker模块

StartServers 2 #推荐设置:小=默认 中=3~5 大=5~10
MaxClients 150 #推荐设置:小=500 中=500~1500 大型=1500~3000
MinSpareThreads 25 #推荐设置:小=默认 中=50~100 大=100~200
MaxSpareThreads 75 #推荐设置:小=默认 中=80~160 大=200~400
ThreadsPerChild 25 #推荐设置:小=默认 中=50~100 大型=100~200
MaxRequestsPerChild 0 #推荐设置:小=10000 中或大=10000~50000
(此外,如果MaxClients/ThreadsPerChild大于16,还需额外设置ServerLimit参数,ServerLimit必须大于等于 MaxClients/ThreadsPerChild 的值。)

对应的配置参数作用如下:

StartServers 启动Apache时创建的子进程数。

MinSpareServers 处于空闲状态的最小子进程数。
所谓空闲子进程是指没有正在处理请求的子进程。如果当前空闲子进程数少于MinSpareServers,那么Apache将以最大每秒一个的速度产生新的子进程。只有在非常繁忙机器上才需要调整这个参数。此值不宜过大。

MaxSpareServers 处于空闲状态的最大子进程数。
只有在非常繁忙机器上才需要调整这个参数。此值不宜过大。如果你将该指令的值设置为比MinSpareServers小,Apache将会自动将其修改成MinSpareServers+1。

MaxClients 允许同时连接的最大请求数量。
任何超过MaxClients限制的请求都将进入等待队列,直到达到ListenBacklog指令限制的最大值为止。

mpm_prefork
MaxClients表示可以用于处理客户端请求的最大子进程数量,默认值是256。要增大这个值,你必须同时增大ServerLimit。

对于线程型或者混合型的MPM(也就是mpm_beos或mpm_worker),MaxClients表示可以用于处理客户端请求的最大线程数量。线程型的mpm_beos的默认值是50。对于混合型的MPM默认值是16(ServerLimit)乘以25(ThreadsPerChild)的结果。因此要将MaxClients增加到超过16个进程才能提供的时候,你必须同时增加ServerLimit的值。

MinSpareThreads 处于空闲状态的最小线程数。 不同的MPM对这个指令的处理是不一样的:

mpm_worker的默认值是75。这个MPM将基于整个服务器监视空闲线程数。如果服务器中总的空闲线程数太少,子进程将产生新的空闲线程。mpm_netware的默认值是10。既然这个MPM只运行单独一个子进程,此MPM当然亦基于整个服务器监视空闲线程数。mpm_beos和mpmt_os2的工作方式与mpm_netware差不多,mpm_beos的默认值是1;mpmt_os2的默认值是5。

MaxSpareThreads 处于空闲状态的最大线程数。 不同的MPM对这个指令的处理是不一样的:

注: mpm_worker的默认值是250。这个MPM将基于整个服务器监视空闲线程数。如果服务器中总的空闲线程数太多,子进程将杀死多余的空闲线程。mpm_netware的默认值是100。既然这个MPM只运行单独一个子进程,此MPM当然亦基于整个服务器监视空闲线程数。mpm_beos和mpmt_os2的工作方式与mpm_netware差不多,mpm_beos的默认值是50;mpmt_os2的默认值是10。

备注:ServerLimit表示Apache允许创建的最大进程数。 值得注意的是,Apache在编译时内部有一个硬限制ServerLimit 20000(对于mpm_prefork模块为ServerLimit 200000)。你不能超越这个限制。
使用这个指令时要特别当心。如果将ServerLimit设置成一个高出实际需要许多的值,将会有过多的共享内存被分配。如果将ServerLimit和MaxClients设置成超过系统的处理能力,Apache可能无法启动,或者系统将变得不稳定。

注意:在配置相关参数时,请先保证服务器具备足够的硬件性能(例如:CPU、内存等)。 如果发现自启动后,随着服务器的运行时间增加,服务器的内存占用也随之增加,可能是程序中出现内存泄露,请向下调整参数MaxRequestsPerChild的值以降低内存泄露带来的影响,然后尽快找出程序中的问题之所在。

<think>我们正在讨论Apache和Nginx的工作模式及其特点。根据引用内容,Apache三种工作模式,而Nginx采用异步事件驱动的架构。下面我将分别详细说明。 ### Apache三种工作模式及特点: 1. **Prefork MPM(多进程模式)**: - 每个请求由一个独立的子进程处理。 - 每个子进程在任意时间只处理一个请求,因此并发能力有限。 - 适合没有线程安全库的场景,稳定性高,但内存消耗大。 - 引用[5]中提到Apache2.4.23,虽然未直接描述工作模式,但根据历史版本,Prefork是经典模式。 2. **Worker MPM(混合多进程多线程模式)**: - 使用多个子进程,每个子进程生成多个线程,每个线程处理一个连接。 - 线程比进程更轻量,因此能支持更高的并发。 - 但线程共享内存,需要确保模块是线程安全的。 - 引用[3]提到Apache属于重量级服务器,可能与此模式有关。 3. **Event MPM(事件驱动模式)**: - 在Worker基础上改进,引入异步事件处理机制。 - 使用专门的监听线程处理连接,工作线程只处理请求,解决了Keep-Alive连接占用线程资源的问题。 - 支持更高的并发连接,尤其在处理长连接时性能更好。 - 引用[5]的标题提到“Apache三种工作模式及优化”,表明Event模式是优化方向。 ### Nginx的工作模式及特点: - **异步非阻塞事件驱动模型**: - Nginx采用多进程(单主进程+多工作进程)结合事件驱动的架构(引用[1])。 - 主进程负责管理,工作进程实际处理请求,每个工作进程使用异步非阻塞I/O(如Linux的epoll)处理大量并发连接(引用[1][4])。 - 单工作进程可处理数千至上万连接(引用[4]提到高并发能力)。 - **轻量高效**: - 代码量少,资源占用低(引用[3]称Nginx为轻量级服务器)。 - 支持高并发连接,内存消耗远低于Apache(引用[1])。 - **模块化设计**: - 功能可通过模块扩展(引用[1][4]),但原生功能较Apache少(引用[2]提到Apache有更多第三方支持)。 - **典型应用场景**: - 反向代理、负载均衡(引用[4])、静态资源服务、虚拟主机等。 ### 对比总结: | **特性** | **Apache** | **Nginx** | |----------------|-----------------------------------------|----------------------------------------| | **架构模型** | 多进程/多线程(Prefork/Worker/Event) | 异步事件驱动(多进程+epoll/kqueue) | | **并发能力** | 较低(Prefork/Worker)到较高(Event) | 极高(单进程万级连接)[^1][^4] | | **内存消耗** | 较高(尤其Prefork) | 较低(约Apache的1/10)[^1] | | **配置管理** | 复杂(.htaccess分布式配置)[^2] | 简洁易读[^1] | | **功能扩展** | 模块丰富(如mod_rewrite, mod_ssl)[^1] | 原生功能少,依赖第三方模块[^1][^2] | | **稳定性** | 高(成熟) | 较高(轻量但相对新)[^3] | > **关键结论**:Nginx在并发处理和资源效率上优势明显,适合高负载场景;Apache在功能丰富性和成熟度上更优,尤其适合需要.htaccess动态配置的共享主机环境[^2]。 ### 配置示例: **Apache (Event MPM)**: ```apache <IfModule mpm_event_module> StartServers 3 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 MaxRequestWorkers 400 ServerLimit 16 </IfModule> ``` **Nginx**: ```nginx worker_processes auto; # 匹配CPU核心数 events { worker_connections 10240; # 单进程连接数 use epoll; # Linux事件模型 } ``` ### 相关问题: 1. Apache的Event模式如何解决Keep-Alive连接的性能瓶颈? 2. Nginx的epoll模型在哪些场景下性能优于Apache? 3. 如何根据服务器硬件配置选择Apache工作模式? 4. Nginx作为反向代理时如何优化后端连接处理?</think>### Apache与Nginx工作模式深度解析 #### 一、Apache三种工作模式及特点 1. **Prefork MPM(多进程模式)** - **原理**:主进程预创建多个子进程,每个子进程独立处理一个连接 - **特点**: - 每个请求独占一个进程,隔离性好 - 无需线程安全库支持 - 内存消耗大(进程开销约5-10MB/连接) - 并发能力有限(约300-500连接/进程) - **适用场景**:兼容老旧模块、非线程安全应用[^5] 2. **Worker MPM(混合进程-线程模式)** - **原理**:主进程管理多个子进程,每个子进程生成多个线程(1线程=1连接) - **特点**: - 线程比进程轻量(内存消耗降低30-50%) - 支持更高并发(约2000连接/进程) - 需线程安全模块支持 - 线程间资源竞争可能引发性能瓶颈 - **适用场景**:高并发静态资源服务[^5] 3. **Event MPM(事件驱动模式)** - **原理**:异步事件模型,使用专用线程管理连接(工作线程专注请求处理) - **特点**: - 解决Worker模式中线程被Keep-Alive连接占用的问题 - 支持数万并发连接 - 最节省内存的Apache模式 - 需要Apache 2.4+版本 - **适用场景**:大量长连接应用(如WebSocket)[^5] > **Apache架构共性**: > - 依赖.htaccess实现目录级配置(灵活性高但性能损耗约20%)[^2] > - 模块化设计(支持70+核心模块如mod_rewrite/mod_ssl)[^1] > - 重量级架构(代码量约70万行)[^3] #### 二、Nginx工作模式及特点 **核心架构**:异步非阻塞事件驱动 - **进程模型**: ```mermaid graph LR Master[主进程] --> Worker1[工作进程1] Master --> Worker2[工作进程2] Worker1 --> EventLoop1[事件循环] Worker2 --> EventLoop2[事件循环] EventLoop1 --> Conn1[连接1] EventLoop1 --> Conn2[连接2] ``` - 主进程:配置文件加载/工作进程管理 - 工作进程:事件驱动处理请求(通常1进程/CPU核心)[^1] - **事件处理机制**: - Linux系统:`epoll`(高效就绪队列管理) - FreeBSD系统:`kqueue` - 单进程可处理10万+并发连接[^4] - **关键优势**: - **低内存消耗**:连接仅需约250KB内存[^1] - **零拷贝技术**:sendfile直接传输文件(无需内核-用户空间复制) - **无阻塞处理**:I/O操作异步完成,CPU利用率近100% - **配置简洁**:声明式配置(vs Apache指令式)[^1] - **典型应用场景**: ```nginx # 反向代理示例 upstream backend { server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080; } ``` - 静态资源服务(吞吐量比Apache高5-10倍) - 反向代理与负载均衡(支持轮询/IP哈希/权重)[^4] - API网关(Lua脚本扩展)[^4] #### 三、核心差异对比 | **特性** | **Apache** | **Nginx** | |------------------|--------------------------------|--------------------------------| | **并发模型** | 进程/线程绑定连接 | 事件驱动异步非阻塞 | | **10k连接内存** | 1-2GB (Prefork) | 250-500MB | | **配置机制** | .htaccess动态加载 | 启动时编译配置 | | **长连接支持** | 线程被占用(Worker) | 事件回调无阻塞 | | **热部署** | 需重启进程 | 无缝重载配置 | | **代码规模** | 约70万行(重量级) [^3] | 约15万行(轻量级) | > **性能测试数据**:相同硬件下Nginx的静态文件吞吐量可达Apache的3-5倍,内存消耗仅为1/5[^1][^3] #### 四、选择建议 - **选Apache**: - 需要.htaccess动态配置(共享主机环境)[^2] - 依赖特定模块(如mod_rewrite深度定制) - 传统LAMP应用兼容性要求高 - **选Nginx**: - 高并发场景(>5000并发连接) - 反向代理/负载均衡需求 - 资源受限环境(低内存服务器) - 静态内容/API网关服务 > **混合架构**:常见实践中,Nginx前置处理静态请求和负载均衡,Apache后端运行动态应用(如PHP)[^1] --- ### 相关问题 1. Apache的Event模式如何解决Keep-Alive连接的性能瓶颈? 2. Nginx的epoll模型在哪些场景下性能优于Apache的Worker模式? 3. 如何根据服务器硬件配置选择Apache工作模式? 4. Nginx作为反向代理时如何优化后端连接处理?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值