网站现部署在国外的服务器，租用虚拟主机来运营，因为访问量比较大，所以经常会收到虚拟主机服务商的流量很大的通知，要求控制下访问量。
1. Web 浏览器向一个特定的服务器发出 Web 页面请求; 2. Web 服务器接收到 web 页面请求后，寻找所请求的 web 页面，并将所请求的 Web 页面传送给 Web 浏览器; 3. Web 浏览器接收到所请求的 web 页面内容，并将它显示出来。
三个步骤都关系 Web 服务器，但实际 Web 服务器性能相关最大的是在第 2 步，这里 Web 服务器需要寻找来自浏览器所请求的 Web 页面内容。
我们知道，Web 页面内容有静态的，也有动态的，静态的内容，web 服务器可以直接将结果发回给浏览器，对于动态内容，则通常需要交给应用服务器先处理，由应用服务器返回结果。
当然，也有 Web 服务器本身可以处理动态内容的，例如 IIS 就可以自已解释处理这两种微软的动态网页脚本语言。
从简要的分析里，我们大致可以得到这样的结论，影响 Web 页面访问的影响因素会有这几个：
8 项很容易理解，也很直接，其实还有以下几项也是关乎 Web 页面访问速度体验的因素，你可以思考下是否如此?或者说是否会影响到页面访问性能。
Web 服务器读取日志文件、写日志内容、关闭对日志文件访问的时间，先读后写再关闭，这三步中的读与写又涉及到磁盘访问性能因素;
尽可能多地使用静态内容，这样 Web 服务器就可以无需请求应用服务器，直接将 Web 内容发给浏览器端，这里可以入手的方案又有：
经过前面小节的简要分析，我相信你对优化 Web 服务器有一定的思了，你可以从硬件层面、软件层面、Web 代码三个层面去优化。
下面我们结合一个具体的实例来实践一回，本文所举例是一个小型的 Web 站点，部分数据系假设，如有类同，纯属巧合，仅起抛砖引玉之用。在实际工作中，如果碰到大站点，你可以参考此处的分析，修改优化方案。
一个社区论坛站点，采用 Discuz! 论坛程序构建，该程序采用主流的 PHP + MySQL 组成。
网站目前有近 5 万注册用户，绝大多数是国内的用户，活跃用户数在一半左右，每天平均 PV 在 15~20 万，访问 IP 数在 8000 左右。
网站现部署在国外的服务器，租用虚拟主机来运营，因为访问量比较大，所以经常会收到虚拟主机服务商的流量很大的通知，要求控制下访问量。
另外，虚拟主机的服务器在美国，没有在国内租用虚拟主机的原因是国内网站在备案方面非常繁琐，在网站一开始运营时数据量和访问量都比较小，所以对性能要求不高，数据量小，所以服务器在查询处理数据时速度比较快，也让人感觉访问速度不慢，现在随着数据量和访问量的不断上升，访问速度已明显下降，到了需要改善访问性能的时候了。
基于目前该社区网站的情况，提出的优化需求是，国内访问速度需要提升一倍，目前首页加载时间需要 40 秒左右，希望优化后能在 20 秒以内将首页加载完成。
根据其网站的现状和优化需求，结合自己的经验，加上谷歌的搜索，同时与网站主不断确认沟通，最终得到以下性能优化方案：
虚拟主机受限比较多，无法自己自定义配置 Web 服务器，无法配置 PHP 动态缓存，而且服务器可以独享内存、处理器资源，不再受虚拟主机商对每个虚拟主机用户的内存和处理器资源占用。处理器资源和内存资源，对接受更多并发访问有直接性能提升效果。
选用 Nginx 而不用 Apache 的原因非常直接和干脆，因为站点里有很多静态的附件文件，在处理静态内容上，Nginx 性能是 Apache 的差不多 10 倍。
在 PHP 解释和伪静态规则方面，Apache 要比 Nginx 强，但这不影响我们放弃它，为缓解这一点，我们在后面对 PHP 进行了动态缓存。
PHP 加速器是一个为了提高 PHP 执行效率，从而缓存起 PHP 的操作码，这样 PHP 后面执行就不用解析转换了，可以直接调用 PHP 操作码，这样速度上就提高了不少。
eAccelerator 是一个开源 PHP 加速器，优化和动态内容缓存，提高了 PHP 脚本的缓存性能，使得 PHP 脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。使得的 PHP 程序代码执效率能提高 1-10 倍，这个加速还常明显的。
缓存使用物理内存来进行，不使用磁盘来缓存。我们知道内存的读写性能是硬盘的 N 倍，所以在内存资源可以安排情况下，强烈使用内存来保存 eAccelerator 的缓存内容。
缓存大小设置为 32MB，这个值是操作系统默认支持最大的缓存容量。虽然可以通过修改配置文件来加大这个值，但我们觉得没有必要，所以就放弃了。
选用了 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 没有 PHP 模块，所以它对 PHP 的支持是通过 PHP-FPM 来实现的，PHP-FPM 是跑进程来处理并发请求，在这个案例中，我们配置了 20 个进程，每个进程差不多占用 20M 左右内存资源，一共是 400M 左右。
同时，PHP-FPM 与 Nginx 交互机制，选用 Linux Socket 模式而不是 TCP 协议端口，Socks 是系统级处理模式，socks 也就是一个文件连接，而 TCP 协议端口，需要经过网络协议处理，性能不如前者，所以我们选择了前者。
因为网站主程序是选用他人开发的开源程序，所以对数据库查询的程序优化我们无法处理，只能从 MySQL 本身寻找突破口。
我们可以想像一下，对于论坛网站，通常看贴、查贴的访问量要远大于创建贴子、回复贴子的访问量，体现在 MySQL 数据库上，就是读表与查询表数据的连接处理更多。
因此我们要选择对读表、查询性能更好的存储引擎，结合以前了解的知识，MySQL 缺省的 MyISAM 引擎就是被设计为适合处理读频率远大于写频率的，查询效率相当可观，而且内存占用很少，这也与我们租用低内存配置的 VPS 相符。
具体到 MySQL 配置参数的优化上，受限于服务器上内存资源本身有限，就直接采用缺省的中型配置文件。
站点每天十多万的访问，上万 IP 访问，查看先前的访问统计，访问来自国内各个地区，使用多种网络连接访问进来，为来自各网络的用户访问速度，同时也减少对网站服务器的请求，我们采用了 CDN 来分发静态内容，这样各地的用户可以就近访问到已缓存在 CDN 上的文件，CDN 服务商会在静态内容第一次访问时缓存到他们全国各地的服务器上，当第二次访问时，用户实际是没有连接到网站服务器上获取文件的，而是直接从 CDN 服务器上获取，可以明显的提升网站性能。返回搜狐，查看更多
网友评论 ()条 查看