优化目标：在高并发量的情况下， 降低用户等待时间，提升吞吐量。
优化方案：

1. 动态内容缓存
2. 浏览器缓存
3. 反向代理
4. 组件分离
5. 分布式缓存
6. 数据库优化
7. 负载均衡
8. 共享文件系统
9. 内容分发
10. 分布式文件系统
11. 分布式计算
12. 扩展数据库

优化思路浅析

要优化 Web 服务器的性能，我们先来看看 Web 服务器在 web 页面处理上的步骤：

1. Web 浏览器向一个特定的服务器发出 Web 页面请求; 2. Web 服务器接收到 web 页面请求后，寻找所请求的 web 页面，并将所请求的 Web 页面传送给 Web 浏览器; 3. Web 浏览器接收到所请求的 web 页面内容，并将它显示出来。

上面三个步骤都关系 Web 服务器，但实际 Web 服务器性能相关最大的是在第 2 步，这里 Web 服务器需要寻找来自浏览器所请求的 Web 页面内容。

我们知道，Web 页面内容有静态的，也有动态的，静态的内容，web 服务器可以直接将结果发回给浏览器，对于动态内容，则通常需要交给应用服务器先处理，由应用服务器返回结果。

当然，也有 Web 服务器本身可以处理动态内容的，例如 IIS 就可以自已解释处理 ASP, ASP.NET 这两种微软的动态网页脚本语言。

从上面简要的分析里，我们大致可以得到这样的结论，影响 Web 页面访问的影响因素会有这几个：

1. Web 服务器从磁盘中读取静态页面内容的速度，也即时间；

2. Web 服务器判定请求内容是静态还是动态内容的时间；

3. Web 服务器转发请求给应用服务器的时间；

4. 应用服务器处理（解释）动态内容所需的时间；

5. Web 服务器返回 Web 内容给浏览器的响应时间；

6. Web 服务器接收来自浏览器请求的处理性能；

7. Web 访问请求数据在网络上传输的时间：包括从浏览器到服务器，和从服务器到浏览器两部分；

8. 浏览器本地计算和渲染 Web 内容的时间，即接收内容后展现内容的时间。

上面 8 项很容易理解，也很直接，其实还有以下几项也是关乎 Web 页面访问速度体验的因素，你可以思考下是否如此？或者说是否会影响到页面访问性能。

• Web 服务器执行安全策略检查的时间，或者说性能；

• Web 服务器读取日志文件、写日志内容、关闭对日志文件访问的时间，先读后写再关闭，这三步中的读与写又涉及到磁盘访问性能因素；

• 同时与 Web 服务器连接会话的客户端数量大小，即并发访问量多大。

我们可以将上面一共 11 项影响因素抽像出来，那么就是：

1. Web 服务器磁盘性能；

2. Web 服务器与应用服务器交互的性能；

3. 应用服务器处理动态内容的性能，或者说动态内容应用处理性能；

4. 客户端与 Web 服务器的连接速度，即网络传输性能；

5. Web 浏览器解释和渲染 Web 内容的性能；

6. Web 访问并发性能。

反映到我们进行性能优化，可以入手的角度就有：

1. 增加带宽，包括服务器和客户端两边的 Internet 连接带宽；

2. 加快动态内容的处理性能；

3. 尽可能多地使用静态内容，这样 Web 服务器就可以无需请求应用服务器，直接将 Web 内容发给浏览器端，这里可以入手的方案又有：

• 动态内容缓存

• 动态内容静态化

多台服务器负载均衡同时处理大量的并发访问；

提升服务器磁盘访问性能，也即通常所说的 I/O 性能；

减少网页中的 HTTP 请求数；

更换更好性能的 Web 服务器；

合理部署服务器，在离客户端更近的地方部署服务器，已经证明可以明显地提升访问性能。

性能优化实践

经过前面小节的简要分析，我相信你对优化 Web 服务器有一定的思路了，你可以从硬件层面、软件层面、Web 代码三个层面去优化。

下面我们结合一个具体的实例来实践一回，本文所举例是一个小型的 Web 站点，部分数据系假设，如有类同，纯属巧合，仅起抛砖引玉之用。在实际工作中，如果碰到大站点，你可以参考此处的分析，修改优化方案。

1. 站点简介

一个社区论坛站点，采用 Discuz! 论坛程序构建，该程序采用主流的 PHP + MySQL 组成。

网站目前有近 5 万注册用户，绝大多数是国内的用户，活跃用户数在一半左右，每天平均 PV 在 15~20 万，独立访问 IP 数在 8000 左右。

2. Web 服务器性能优化需求

网站现部署在国外的服务器，租用虚拟主机来运营，因为访问量比较大，所以经常会收到虚拟主机服务商的流量很大的通知，要求控制下访问量。

另外，虚拟主机的服务器在美国，没有在国内租用虚拟主机的原因是国内网站在备案方面非常繁琐，在网站一开始运营时数据量和访问量都比较小，所以对性能要求不高，数据量小，所以服务器在查询处理数据时速度比较快，也让人感觉访问速度不慢，现在随着数据量和访问量的不断上升，访问速度已明显下降，到了需要改善访问性能的时候了。

基于目前该社区网站的情况，提出的优化需求是，国内访问速度需要提升一倍，目前首页加载时间需要 40 秒左右，希望优化后能在 20 秒以内将首页加载完成。

另外提出网站数据能够每天自动备份一次，备份数据保留一个月的，以便随时恢复。

上述两点需求，其中第一条才是性能优化需求，第二条是额外的需求了。

3. 性能优化方案

根据其网站的现状和优化需求，结合自己的经验，加上谷歌的搜索，同时与网站主不断确认沟通，最终得到以下性能优化方案：

由虚拟主机部署改为独立服务器部署

虚拟主机受限比较多，无法自己自定义配置 Web 服务器，无法配置 PHP 动态缓存，而且独立服务器可以独享内存、处理器资源，不再受虚拟主机商对每个虚拟主机用户的内存和处理器资源占用限制。处理器资源和内存资源，对接受更多并发访问有直接性能提升效果。

独立服务器，我们选用 Linode 2048 型号，2G 内存，4 核处理器（Linode 所有 VPS 都是四核处理器），80G 硬盘空间，800G 网络流量。

由 Windows 操作系统改为 Linux 操作系统

网站使用的是 PHP + MySQL 程序，PHP 在 Windows 下的性能，受限于 IIS 需要通过 ISAPI 形式调用 PHP，所以性能不如 Linux 下 Apache 直接通过 PHP 模块解释 PHP，更不如 Nginx 与 PHP-FPM 的性能，既然使用了独立服务器，操作系统也可以自己确定，Linux 系统我们选用了熟悉的 Ubuntu Linux Server 10.04（一年前还没有 12.04），^-^。

Web 服务器采用 Nginx，而不使用 Apache

选用 Nginx 而不用 Apache 的原因非常直接和干脆，因为站点里有很多静态的附件文件，在处理静态内容上，Nginx 性能是 Apache 的差不多 10 倍。

在 PHP 解释和伪静态规则方面，Apache 要比 Nginx 强，但这不影响我们放弃它，为缓解这一点，我们在后面对 PHP 进行了动态缓存。

对 PHP 查询进行动态缓存，使用 eAccelerator 这个加速器

PHP 加速器是一个为了提高 PHP 执行效率，从而缓存起 PHP 的操作码，这样 PHP 后面执行就不用解析转换了，可以直接调用 PHP 操作码，这样速度上就提高了不少。

eAccelerator 是一个开源 PHP 加速器，优化和动态内容缓存，提高了 PHP 脚本的缓存性能，使得 PHP 脚本在编译的状态下，对服务器的开销几乎完全消除。 它还有对脚本起优化作用，以加快其执行效率。使得的 PHP 程序代码执效率能提高 1-10 倍，这个加速还是非常明显的。

具体地，我们计划对 eAccelerator 进行以下设置优化：

• 缓存使用物理内存来进行，不使用磁盘来缓存。我们知道内存的读写性能是硬盘的 N 倍，所以在内存资源可以安排情况下，强烈建议使用内存来保存 eAccelerator 的缓存内容。

• 缓存大小设置为 32MB，这个值是操作系统默认支持最大的缓存容量。虽然可以通过修改配置文件来加大这个值，但我们觉得没有必要，所以就放弃了。

Nginx 性能优化

选用了 Nginx，虽然它的性能很好，但我们仍然需要对它进行性能优化，在这个案例中，我们做了以下优化：

• 使用 8 个进程，每个进程大约需要 20M 内存消耗，这里一共使用了 150M 左右的内存。

• 充分使用主服务器的 CPU 内核：四核，使用 CPU 粘性配置选项(worker_cpu_affinity)，每核处理器分配两个进程。

• 开启 gzip 压缩功能：gzip 压缩对 JS, CSS, XML 压缩效果非常好，能压缩一半，即减少一倍的传输时间；对图片文件，JPG 已经压缩过的，它的压缩性能要少一些。

• 图片本地缓存 1 天：网站上的图片很多，通常一张图片上传后，不会频繁的修改，只会频繁的访问，所以将图片放在 Nginx 缓存里，可以减少服务器访问加载次数，提升访问速度。

• JS、CSS 文件本地缓存 7 天：这两种网页文件，平时都不会去修改它，将它缓存起来，可以减少加载次数，提升访问速度。为什么这两种文件不和图片一起设置缓存有效期，是考虑了不同文件的修改频率不一样。

• Nginx 日志每天切割一次：这个优化项能大大减小 Nginx 日志文件的大小，经过一周的查看，每天的日志文件是 50M 左右，如果不是每天切割，用月切割，那一个月的日志文件就是几个 G，要 Web 服务器在内存里加载这么大的文件，系统本身内存不够用，就自然会用到磁盘来缓存，这就影响性能。每天 50M 左右，在内存上完全可以顺利加载，这样 Nginx 在处理访问时，可以快速的保存访问日志。

经过上述几个优化项目，Nginx 这边一共需要占用 200M 左右内存资源。

对 PHP CGI 进程性能进行优化

Nginx 没有 PHP 模块，所以它对 PHP 的支持是通过 PHP-FPM 来实现的，PHP-FPM 是跑进程来处理并发请求，在这个案例中，我们配置了 20 个进程，每个进程差不多占用 20M 左右内存资源，一共是 400M 左右。

同时，PHP-FPM 与 Nginx 交互机制，选用 Linux Socket 模式而不是 TCP 协议端口，Socks 是系统级处理模式，socks 也就是一个文件连接，而 TCP 协议端口，需要经过网络协议处理，性能不如前者，所以我们选择了前者。

MySQL 数据库性能优化

因为网站主程序是选用他人开发的开源程序，所以对数据库查询的程序优化我们无法处理，只能从 MySQL 本身寻找突破口。

我们可以想像一下，对于论坛网站，通常看贴、查贴的访问量要远大于创建贴子、回复贴子的访问量，体现在 MySQL 数据库上，就是读表与查询表数据的连接处理更多。

因此我们要选择对读表、查询性能更好的存储引擎，结合以前了解的知识，MySQL 缺省的 MyISAM 引擎就是被设计为适合处理读频率远大于写频率的环境，查询效率相当可观，而且内存占用很少，这也与我们租用低内存配置的 VPS 相符。

具体到 MySQL 配置参数的优化上，受限于服务器上内存资源本身有限，就直接采用缺省的中型环境配置文件。

内容分发网络应用

站点每天十多万的访问，上万独立 IP 访问，查看先前的访问统计，访问来自国内各个地区，使用多种网络连接访问进来，为保证来自各网络的用户访问速度，同时也减少对网站服务器的请求，我们采用了 CDN 来分发静态内容，这样各地的用户可以就近访问到已缓存在 CDN 上的文件，CDN 服务商会在静态内容第一次访问时缓存到他们全国各地的服务器上，当第二次访问时，用户实际是没有连接到网站服务器上获取文件的，而是直接从 CDN 服务器上获取，可以明显的提升网站性能。

版权申明：本站文章均来自网络，如有侵权，请联系01056159998 邮箱：itboby@foxmail.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有