Web服务器优化详细说明

　　服务器过载的情况分为两种：

　　一种为瞬间过载，即服务器暂时的、短时间的超载，这种情况主要是由服务器负载的特点引起的。大量的研究表明，Web请求的网络通信量分布是自相似的，即Web请求的通信量可以在很大范围内有显著的变化。

　　一种是服务器长时间的超载，这种情况一般是由某一特殊事件引起的，例如服务器受到拒绝服务攻击或者发生了“活锁”现象。

　　第一种服务器超载情况是不可避免的

　　第二种情况则可以通过对服务器改进来改善。抛开恶意的攻击不算，仔细分析服务器处理信息包的过程可以发现，造成系统在超载情况下性能下降的根本原因是高优先级处理阶段对CPU的不公平抢占。

　　架构分两种来讨论的，一种是开发架构，一种是部署架构

　　部署架构，就是开发完的程序在实际运行环境下，通过负载均衡，DNS轮询，SquID等等来减轻单台服务器负载，达到性能优化的目的

　　开发上的架构

　　1、数据库优化，这个是所有的优化策略中中重要的，可以说数据库设计的好坏，直接影响了一个系统的承受力。普通的数据库细节优化，网上已经有大笔文章了，没什么好说的，想了解的自己去找。而我要说的就是在数据库设计中的一个思路，分库、分表、缓存表。

　　1)分库指的是在设计中，要考虑到后期数据量大的情况下，你的数据库能够随着应用随时拆分，这个拆分并不是只是针对功能模块对应的数据拆分。举个例子，就用这个CSDN论坛吧，比如里面有很多类，C#版，JAVA版，系统设计版等等，拆分的目的是可以把任何一个版的数据拆分到单独的一个数据库中去。

　　2)分表相对的就好理解了，就是说同类型的数据，你可以为了性能优化，进行拆分到多个表中去，拆分规则可以有多种，按照类型、按照时间、按照姓名等等。同样以这个CSDN论坛来说，我要设计的话，我会按照里面的大版面进行数据库拆分，而按照小版，进行表拆分。

　　3)而对于缓存表，网上我还很少看到有人来说这个东西，这个的目的就是针对一个大的数据表中，一般中有死数据库和活动数据，比如用户表，里面有很多基本不来的用户，那么针对这样的情况，当表数据上了千万的时候，我就会采用缓存表的模式来进行了，就是在实际表和用户之间在搭建一个临时表，访问用户数据时，首先访问临时表，如果不存在，则进入实际表中获取，然后放入缓存表中，同时会通过后台线程，定时将缓存表数据同步到实际数据库中，同步时间可以针对系统要求来进行。

　　程序优化

　　1)首推静态化，这个的优化效果不用多说，直接减轻了服务器负担，不过如果用上了Squid，那么有第三放来做静态，也可以达到同样的效果

　　2)合适的数据缓存，缓存很多人都用到了，但是在使用前，是否认真思考过为这个这个要进行Cache，Cache他的标准是什么?我说下我的标准：小数据量、大访问量、更新尽量少的数据，全部可以进行缓存。另外我提到的缓存，并不只是说。NET本身提供的Cache，我说的缓存还包括了使用Static来进行的数据

　　3)活用线程，很多人的观念中感觉线程好象在B/S中是用不到的，或者是没有必要。其实这个观念完全错，在特定情况下使用线程，可以提高的局部性能不是一点两点

　　4) 功能模块拆分，这个一般人基本都在做，我要补充的是，不只是在单个项目中进行功能模块的拆分，而是为了进行分步式开发而进行拆分

　　一个WEB 服务器，一个DB服务器，主题帖千万，回复帖有6000W左右吧，其它数据不算，运行过程中没出过任何问题，日访问在100W PV情况下，还没有达到性能瓶颈

　　在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

　　HTML静态化

　　其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面.信息发布系统CMS，各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能.

　　除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。目前很多博客也都实现了静态化，我使用的这个 Blog程序WordPress还没有静态化

　　图片服务器分离

　　对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

　　在应用服务器和图片服务器上，可以进行不同的配置优化，比如Apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

　　数据库集群和库表散列

　　在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

　　从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

　　在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

　　缓存

　　架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的mod_proxy缓存模块，也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

　　网站程序开发方面的缓存，Linux上提供的Memcached是常用的缓存方案，不少web编程语言都提供memcache访问接口，php、 perl、c和java都有，可以在web开发中使用，可以实时或者Cron的把数据、对象等内容进行缓存，策略非常灵活。一些大型社区使用了这样的架构。

　　另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块和eAccelerator加速和Cache模块，还要知名的Apc、XCache,php缓存模块，Java就更多了.

　　镜像

　　镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异

　　负载均衡

　　负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择,有关初级的负载均衡DNS轮循和较专业的CDN架构。

　　硬件四层交换

　　第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

　　在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

　　软件四层交换

　　大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

　　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

　　一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

　　CDN是什么

　　CDN(Content Delivery Network)，就是内容发布网或者内容分发网，它的主要目的：通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可以就近取得所需的内容，从而提高用户访问网站的响应速度，提升用户体验，同时能够分散访问压力，把本来用户集中访问分散到各地去。网站的内容提供商(比如新浪、搜狐、网易等等)使用CDN，就可以在宏观层解决一部分大流量、海量用户并发等令人头疼的问题。

　　CDN的组成

　　内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要件，而内容管理和全局的网络流量管理是 CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务，达到用户所要求的服务距用户仅有"一跳"(Single Hop)之遥。

　　CDN服务提供商

　　ChinaCache是中国最大的CDN服务提供商，是不是唯一未可知也。要想成为CDN服务提供商，恐怕要摆平电信、网通、铁通等等运营商，这得需要什么样的能力和背景不得而知。它的服务节点在全球已经超过130个，其中国内节点超过80个，覆盖全国主要6大网络(所谓6线机房，就是这么来的)的主要省份，象各大门户网站，比如新浪、网易等等都是租用了他们的服务。所以，你无论是在南方，或者北方，还是在北美，访问这些门户网站，感觉速度都很快，最主要的原因之一就是CDN发挥了效果。

　　如果想继续提升用户体验的话，就需要做一些网站镜像，部署在具有代表性的几个大城市，比如华南可以部署在广州，华东可以部署在上海，华北可以部署在北京，不过内容镜像的过程，就需要自己去部署和维护。还有的网站，采用内容分割的方式，比如建立针对各地的分站，业务情况不同，可能部署的策略不同。CDN可以认为是基础网络建设的一种策略。

　　前面介绍了cdn的一些原理和概念，以及提供cdn基础网络服务的途径。cdn看起来对于静态内容的，比如html,js,image是非常合适的，通过cdn的部署，用户只需要一跳就可以访问到网站的内容。那对于动态内容怎么办呢?我回答一下：

　　动态内容按照存在形态可以分为三类。

　　第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。

　　第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时静化，像Mop的大杂烩、网易社区就是使用了这样的策略。

　　第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。

　　对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。

　　对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。

　　1. 负载均衡的分类

　　负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡是基于硬件技术的均衡;

　　按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。

　　各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。

　　2. DNS轮询均衡

　　这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命令。比如：nslookup www。163。com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。

　　DNS轮询均衡的优点：

　　1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供;

　　2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。

　　DNS轮询均衡的缺点：

　　1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。

　　2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。

　　Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大的影响。

　　3. OSI七层模型

　　我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。

　　OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。

　　OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，

　　所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

　　OSI 7层的功能描述：

　　(1)应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示例：telnet，HTTP,FTP,WWW,NFS,SMTP等。

　　(2)表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的字符集。示例：加密，ASII等。

　　(3)会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。

　　(4)传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对的数据包的重新排序功能。示例：TCP，UDP，SPX。

　　(5)网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。

　　(6)数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。

　　(7)物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。

　　Apache2.0性能优化—MPM的选择与配置

　　prefork的工作原理及配置

　　如果不用“--with-mpm”显式指定某种MPM，prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache 1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性;另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的，这也使其成为最稳定的MPM之一。

　　若使用prefork，在make编译和make install安装后，使用“httpd -l”来确定当前使用的MPM，应该会看到prefork.c(如果看到worker.c说明使用的是worker MPM，依此类推)。再查看缺省生成的httpd.conf配置文件，里面包含如下配置段：

　　;

　　StartServers 5

　　MinSpareServers 5

　　MaxSpareServers 10

　　MaxClients 150

　　MaxRequestsPerChild 0

　　;

　　prefork的工作原理是，控制进程在最初建立“StartServers”个子进程后，为了满足MinSpareServers设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足 MinSpareServers设置的值为止。这就是预派生(prefork)的由来。这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。

　　MaxSpareServers设置了最大的空闲进程数，如果空闲进程数大于这个值，Apache会自动kill掉一些多余进程。这个值不要设得过大，但如果设的值比MinSpareServers小，Apache会自动把其调整为MinSpareServers+1。如果站点负载较大，可考虑同时加大MinSpareServers和MaxSpareServers。

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

　　◆ 可防止意外的内存泄漏;

　　◆ 在服务器负载下降的时侯会自动减少子进程数。

　　因此，可根据服务器的负载来调整这个值。笔者认为10000左右比较合适。

　　MaxClients是这些指令中最为重要的一个，设定的是Apache可以同时处理的请求，是对Apache性能影响最大的参数。其缺省值 150是远远不够的，如果请求总数已达到这个值(可通过ps -ef|grep http|wc -l来确认)，那么后面的请求就要排队，直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很慢的主要原因。系统管理员可以根据硬件配置和负载情况来动态调整这个值。虽然理论上这个值越大，可以处理的请求就越多，但Apache默认的限制不能大于256。如果把这个值设为大于256，那么 Apache将无法起动。事实上，256对于负载稍重的站点也是不够的。在Apache 1.3中，这是个硬限制。如果要加大这个值，必须在“configure”前手工修改的源代码树下的src/include/httpd.h中查找 256，就会发现“#define HARD_SERVER_LIMIT 256”这行。把256改为要增大的值(如4000)，然后重新编译Apache即可。在Apache 2.0中新加入了ServerLimit指令，使得无须重编译Apache就可以加大MaxClients。下面是笔者的prefork配置段：

　　;

　　StartServers 10

　　MinSpareServers 10

　　MaxSpareServers 15

　　ServerLimit 2000

　　MaxClients 1000

　　MaxRequestsPerChild 10000

　　;

　　上述配置中，ServerLimit的最大值是20000，对于大多数站点已经足够。如果一定要再加大这个数值，对位于源代码树下server/mpm/prefork/prefork.c中以下两行做相应修改即可：

　　#define DEFAULT_SERVER_LIMIT 256

　　#define MAX_SERVER_LIMIT 20000

　　worker的工作原理及配置

　　相对于prefork，worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是， worker也使用了多进程，每个进程又生成多个线程，以获得基于进程服务器的稳定性。这种MPM的工作方式将是Apache 2.0的发展趋势。

　　在configure -with-mpm=worker后，进行make编译、make install安装。在缺省生成的httpd.conf中有以下配置段：

　　;

　　StartServers 2

　　MaxClients 150

　　MinSpareThreads 25

　　MaxSpareThreads 75

　　ThreadsPerChild 25

　　MaxRequestsPerChild 0

　　;

　　worker的工作原理是，由主控制进程生成“StartServers”个子进程，每个子进程中包含固定的ThreadsPerChild 线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程，MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数;而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。

　　MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大，可以按照实际情况相应调节。

　　ThreadsPerChild是worker MPM中与性能相关最密切的指令。ThreadsPerChild的最大缺省值是64，如果负载较大，64也是不够的。这时要显式使用 ThreadLimit指令，它的最大缺省值是20000。上述两个值位于源码树server/mpm/worker/worker.c中的以下两行：

　　#define DEFAULT_THREAD_LIMIT 64

　　#define MAX_THREAD_LIMIT 20000

　　这两行对应着ThreadsPerChild和ThreadLimit的限制数。最好在configure之前就把64改成所希望的值。注意，不要把这两个值设得太高，超过系统的处理能力，从而因Apache不起动使系统很不稳定。

　　Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的，应该大于等于MaxClients。如果负载很大，现有的子进程数不能满足时，控制进程会派生新的子进程。默认最大的子进程总数是16，加大时也需要显式声明ServerLimit(最大值是 20000)。这两个值位于源码树server/mpm/worker/worker.c中的以下两行：

　　#define DEFAULT_SERVER_LIMIT 16

　　#define MAX_SERVER_LIMIT 20000

　　需要注意的是，如果显式声明了ServerLimit，那么它乘以ThreadsPerChild的值必须大于等于MaxClients，而且 MaxClients必须是ThreadsPerChild的整数倍，否则Apache将会自动调节到一个相应值(可能是个非期望值)。下面是笔者的 worker配置段：

　　;

　　StartServers 3

　　MaxClients 2000

　　ServerLimit 25

　　MinSpareThreads 50

　　MaxSpareThreads 200

　　ThreadLimit 200

　　ThreadsPerChild 100

　　MaxRequestsPerChild 0

　　;

　　通过上面的叙述，可以了解到Apache 2.0中prefork和worker这两个重要MPM的工作原理，并可根据实际情况来配置Apache相关的核心参数，以获得最大的性能和稳定性。

文章来源：http://blog.sina.com.cn/s/blog_71ed1b870100xg16.html