Apache服务器访问过慢分析及解决Word文档格式.docx

1、 #指定服务器启动时建立的子进程数量 MinSpareServers #指定空闲子进程的最小数量 MaxSpareServers 10 #指定空闲子进程的最大数量 MaxClients 150 #指定同一时间客户端最大接入请求的数量（单个进程并发线程数），任何超过该限制的请求都将进入等候队列，一旦一个连接被释放，队列中的请求将得到服务 MaxRequestsPerChild 0 #指定每个子进程在其生存周期内允许伺服的最大请求数量，默认为10000，0表示子进程永远不结束/IfModule prefork 控制进程在最初建立“StartServers”个子进程后，为了满足 MinSpareSe

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

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

4、们可以把MaxClients加得很大，但是往往会适得其反，系统耗光所有内存。以一台服务器为例：内存2G，每个apache进程消耗大约0.5%（可通过ps aux来确认）的内存，也就是10M，这样，理论上这台服务器最多跑200个apache进程就会耗光系统所有内存，所以，设置MaxClients要慎重。 worker 模式： 以 worker 模式工作的 apache 的默认配置为：IfModule mpm_worker_module 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild Worker 由主控制进程生成“StartServ

5、ers”个子进程，每个子进程中包含固定的ThreadsPerChild线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程， MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数；而MaxClients 设置了同时连入的clients最大总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。 MinSpareThreads和 MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大，可以按照实际情况相应调节。 ThreadsPerChild是worker MPM中与性能相关最密切

6、的指令。 ThreadsPerChild的最大缺省值是64，如果负载较大，64也是不够的。这时要显式使用 ThreadLimit指令，它的最大缺省值是20000。 Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild 值决定的，应该大于等于MaxClients。如果负载很大，现有的子进程数不能满足时，控制进程会派生新的子进程。默认最大的子进程总数是16，加大时也需要显式声明ServerLimit（最大值是20000）。需要注意的是，如果显式声明了ServerLimit，那么它乘以 ThreadsPerChild的值必须大于等于MaxClients，而且Max

7、Clients必须是ThreadsPerChild的整数倍，否则 Apache将会自动调节到一个相应值。 服务器的apache采用的是 prefork 的工作模式，对 MaxClients 进行了相应的调整，发现服务启动后很短时间，连接数就能够达到最大。5、后来想到需要查看用户都是访问的那些页面，将配置中的 access_log 打开，发现85%以上的访问都是直接访问的资源文件，由此判定，用户可能使用了多线程的下载工具，或者这些资源遭受了盗链。6、找到了问题所在，进行解决也就比较好办了。想到了两个方法： A、对单个IP进行连接的线程限制，不允许多线程连接资源。 对于IP限制，我采用了 mod_

8、limitipconn 这个模块。这个模块的好处是比较简单，缺点是不能够针对单独的文件夹或者文件进行设置，而且不支持虚拟主机。 在 apache 中安装了这个模块后，在配置文件中添加如下几段就可以生效了： ExtendedStatus On IfModule mod_limitipconn.c Location / # 所有虚拟主机的/目录 MaxConnPerIP 3 # 每IP只允许3个并发连接 NoIPLimit image/* # 对图片不做IP限制 /Location Location /mp3 # 所有主机的/mp3目录 MaxConnPerIP 1 # 每IP只允许一个连接请求

9、OnlyIPLimit audio/mpeg video # 该限制只对视频和音频格式的文件 /IfModule B、添加URL重写，防止盗链。 防止盗链，一个重要的方法就是判断请求的 refer，但是如果使用一些浏览器发出请求的时候将 refer 去掉，或者伪装，这个办法就无能为力了。但是貌似还有更高级的方法，还是可以实现这个功能。 安装apache的 mod_rewrite 模块后，在apache配置文件中添加 RewriteEngine On RewriteCond %HTTP_REFERER ! NC$ NC RewriteRule .*.（gif|jpg|swf）$R,NC 这样盗链

10、的请求会被重定向到一个错误页面，从而减少下载带给服务器的压力。参考资料：1、部署 Apache 的一些技巧。2、Apache Server 负载能力测试3、Apache AB4、Apache的参数设置5、Ab的用法6、Apache限制连接数和并发数7、Apache安装mod_rewrite模块8、Apache防盗链的简单实现Windows系统下如果优化Apache的性能主要是通过专门针对Windows NT优化的MPM（多路处理模块）mpm_winnt.c来优化的，它使用一个单独的父进程产生一个单独的子进程，在这个子进程中轮流产生多个线程来处理请求。也就是说mpm_winnt只能启动父子两个进

11、程, 不能像Linux下那样同时启动多个进程。 mpm_winnt主要通过ThreadsPerChild和MaxRequestsPerChild两个参数来优化Apache。 ThreadsPerChild 这个参数用于设置每个进程的线程数, 子进程在启动时建立这些线程后就不再建立新的线程了. 一方面因为mpm_winnt不能启动多个进程, 所以这个数值要足够大，以便可以处理可能的请求高峰; 另一方面该参数以服务器的响应速度为准的, 数目太大的反而会变慢。因此需要综合均衡一个合理的数值。mpm_winnt上的默认值是64, 最大值是1920. 这里建议设置为100-500之间，服务器性能高的话值

12、大一些，反之值小一些。 MaxRequestsPerChild 该参数表示每个子进程能够处理的最大请求数, 即同时间内子进程数目.设置为零表示不限制, mpm_winnt上的默认值就是0. 官方参考手册中不建议设置为0, 主要基于两点考虑: （1） 可以防止（偶然的）内存泄漏无限进行，从而耗尽内存; （2） 给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。 因此这个参数的值更大程度上取决于服务器的内存，如果内存比较大的话可以设置为0或很大的数字，否则设置一个小的数值。需要说明的是，如果这个值设置的太小的话会造成Apache频繁重启，在日志文件中会看到如下的文字：Proc

13、ess exiting because it reached MaxRequestsPerChild. Signaling the parent，这样一来降低了Apache的总体性能。 另外，可以通过查看Apache提供的server-status（状态报告）来验证当前所设置数值是否合理，在httpd.conf文件中做如下设置来打开它： # 首先需要加载mod_status模块 LoadModule status_module modules/mod_status.so # 然后设置访问的地址 SetHandler server-status Order deny,allow Deny fro

14、m all # 如果限制某个IP访问则设置为 Allow from 192.168.1.1 Allow from all 综合来说，因为Windows NT下Apache只能启动父子两个进程，因此只能通过增大单个进程的线程数以及单个进程能够处理的最大请求数来进行优化。其他优化的参数同Linux系统下是一样的，大家可以加以参考。下面针对上述两个参数给出一个建议的设置：IfModule mpm_winnt.c ThreadsPerChild 250 MaxRequestsPerChild 5000 用上面的方法优化了一下windows+apache+php后，发现响应速度快了很多，一般最多只延迟3

15、秒左右，但对于美国的主机来说应该是个正常的状态吧！大型网站HTTPS实践三：基于协议和配置的优化1 前言上文讲到HTTPS 对用户访问速度的影响。本文就为大家介绍 HTTPS 在访问速度，计算性能，安全等方面基于协议和配置的优化。2 HTTPS 访问速度优化2.1 Tcp fast openHTTPS 和 HTTP 使用 TCP 协议进行传输，也就意味着必须通过三次握手建立 TCP 连接，但一个 RTT 的时间内只传输一个 syn 包是不是太浪费？能不能在 syn 包发出的同时捎上应用层的数据？其实是可以的，这也是 tcp fast open 的思路，简称 TFO。具体原理可以参考 rfc74

16、13。遗憾的是 TFO 需要高版本内核的支持，linux 从 3.7 以后支持 TFO，但是目前的 windows 系统还不支持 TFO，所以只能在公司内部服务器之间发挥作用。2.2 HSTS前面提到过将用户 HTTP 请求 302 跳转到 HTTPS，这会有两个影响：1、不安全，302 跳转不仅暴露了用户的访问站点，也很容易被中间者支持。2、降低访问速度，302 跳转不仅需要一个 RTT，浏览器执行跳转也需要执行时间。由于 302 跳转事实上是由浏览器触发的，服务器无法完全控制，这个需求导致了 HSTS 的诞生：HSTS（HTTP Strict Transport Security）。服务端

17、返回一个 HSTS 的 http header，浏览器获取到 HSTS 头部之后，在一段时间内，不管用户输入还是，都会默认将请求内部跳转成。Chrome, firefox, ie 都支持了 HSTS（2.3 Session resumeSession resume 顾名思义就是复用 session，实现简化握手。复用 session 的好处有两个：1、减少了 CPU 消耗，因为不需要进行非对称密钥交换的计算。2、提升访问速度，不需要进行完全握手阶段二，节省了一个 RTT 和计算耗时。TLS 协议目前提供两种机制实现 session resume，分别介绍一下。2.3.1 Session cac

18、heSession cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存，则直接使用已有的 session 信息提前完成握手，称为简化握手。Session cache 有两个缺点：1、需要消耗服务端内存来存储 session 内容。2、目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于XX或者其他大型互联网公司而言，单机 session cache 几乎没有作用。Session cache 也有一个非常大的优点：session id 是 TLS 协议

19、的标准字段，市面上的浏览器全部都支持 session cache。XX通过对 TLS 握手协议及服务器端实现的优化，已经支持全局的 session cache，能够明显提升用户的访问速度，节省服务器计算资源。2.3.2 Session ticket上节提到了 session cache 的两个缺点，session ticket 能够弥补这些不足。Session ticket 的原理参考 RFC4507。简述如下：server 将 session 信息加密成 ticket 发送给浏览器，浏览器后续握手请求时会发送 ticket，server 端如果能成功解密和处理 ticket，就能完成简化握手

20、。显然，session ticket 的优点是不需要服务端消耗大量资源来存储 session 内容。Session ticket 的缺点：1、session ticket 只是 TLS 协议的一个扩展特性，目前的支持率不是很广泛，只有 60% 左右。2、session ticket 需要维护一个全局的 key 来加解密，需要考虑 KEY 的安全性和部署效率。总体来讲，session ticket 的功能特性明显优于 session cache。希望客户端实现优先支持 session ticket。2.4 Ocsp staplingOcsp 全称在线证书状态检查协议 （rfc6960），用来向

21、CA 站点查询证书状态，比如是否撤销。通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。这个过程非常消耗时间，因为 CA 站点有可能在国外，网络不稳定，RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢？ocsp stapling 就能实现这个功能。详细介绍参考 RFC6066 第 8 节。简述原理就是浏览器发起 client hello 时会携带一个 certificate status request 的扩展，服务端看到这个扩展后将 OCSP 内容直接返回给浏览器，完成证书状态检查。由于浏览器不需要直接向 C

22、A 站点查询证书状态，这个功能对访问速度的提升非常明显。Nginx 目前已经支持这个 ocsp stapling file，只需要配置 ocsp stapling file 的指令就能开启这个功能： ssl_stapling on;ssl_stapling_file ocsp.staple;2.5 False start通常情况下，应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间，那能不能类似 TFO 一样，在完全握手的第二个阶段将应用数据一起发出来呢？google 提出了 false start 来实现这个功能。详细介绍参考https:/tools.ietf.org/htm

23、l/draft-bmoeller-tls-falsestart-00。简单概括 False start 的原理就是在 client_key_exchange 发出时将应用层数据一起发出来，能够节省一个 RTT。False start 依赖于 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依赖于 DHE 密钥交换系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以尽量优先支持 ECDHE 密钥交换算法实现 false start。2.6 使用 SPDY 或者 HTTP2SPDY 是 google 推出的优化 H

24、TTP 传输效率的协议（https:/www.chromium.org/spdy），它基本上沿用了 HTTP 协议的语义, 但是通过使用帧控制实现了多个特性，显著提升了 HTTP 协议的传输效率。SPDY 最大的特性就是多路复用，能将多个 HTTP 请求在同一个连接上一起发出去，不像目前的 HTTP 协议一样，只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送，但是接收时依然得按照顺序接收，本质上无法解决并发的问题。HTTP2 是 IETF 2015 年 2 月份通过的 HTTP 下一代协议，它以 SPDY 为原型，经过两年多的讨论和完善最终确定。本文就不过多介绍 SPDY 和

25、 HTTP2 的收益，需要说明两点：1、SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。2、SPDY 和 HTTP2 都支持现有的 HTTP 语义和 API，对 WEB 应用几乎是透明的。Google 宣布 chrome 浏览器 2016 年将放弃 SPDY 协议，全面支持 HTTP2，但是目前国内部分浏览器厂商进度非常慢，不仅不支持 HTTP2，连 SPDY 都没有支持过。XX服务端和XX手机浏览器现在都已经支持 SPDY3.1 协议。3 HTTPS 计算性能优化3.1 优先使用 ECCECC 椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是 NIST 推荐的密钥长

26、度对照表。表格 2 NIST 推荐使用的密钥长度对于 RSA 算法来讲，目前至少使用 2048 位以上的密钥长度才能保证安全性。ECC 只需要使用 224 位长度的密钥就能实现 RSA2048 位长度的安全强度。在进行相同的模指数运算时速度显然要快很多。3.2 使用最新版的 openssl一般来讲，新版的 openssl 相比老版的计算速度和安全性都会有提升。比如 openssl1.0.2 采用了 intel 最新的优化成果，椭圆曲线 p256 的计算性能提升了 4 倍。（https:/eprint.iacr.org/2013/816.pdf）Openssl 2014 年就升级了 5 次，基本都是为了修复实现上的 BUG 或者算法上的漏洞而升级的。所以尽量使用最新版本，避免安全上的风险。3.3 硬件加速方案现在比较常用的 TLS