Web应用，本质是各种Web内容从Web网站达到浏览器，呈现给用户。用户希望在获取Web内容的时间越短越好。从Web网站的角度，需要解决大量用户并发访问时的时延问题，体现为两大度量指标：吞吐量和并发度。吞吐量指单位时间内能完成请求数（req/s）。并发度指同时发起请求的客户端数量（浏览器发送请求有一定的并发度，例如能同时发送4个请求，在这里算4个客户端）。在一定的并发度下，吞吐量越大，客户感觉的时延就越低，网站的性能就越高。

不同的并发度下，网站的吞吐量并不是一个常量。一般来说，当并发度小于某个阈值时，网站能保持相对稳定的吞吐量；而超过这个阈值，网站的吞吐量则迅速下降。这个阈值决定于网站的消息处理速度。假设网络带宽不是瓶颈，请求消息达到网站后，被缓存在内核的缓冲区队列，然后被并行处理。当网站处理消息的速度赶不上消息缓冲的速度时，队列中消息就会大量堆积，导致处理时延迅速增加，吞吐量迅速下降。在通常的压力测试模型中，一般模拟多个用户并行发送消息，某个用户接受收到上一消息的回应后，才会发下一个消息。所以如果网站消息处理时延延长，消息发送间隔自然延长，单位时间内涌向网站的消息减少，这会导致网站吞吐量下降，从而在一个新的吞吐量下达成消息处理与消息到达的平衡。但在真实的场景中，在访问高峰期，性急的用户会不断刷新浏览器，涌向网站的请求消息量持续超过网站的实际处理能力，请求被大量堆积在网站的缓冲区，直至网站的内存耗尽，导致网站瘫痪。所以，真实场景中为避免网站瘫痪，要采取流量控制措施。

为了加速WEB网站，提升WEB性能，一般有下列措施：

1. 改进服务器IO并发模型。有三种经典IO并发模型：进程并发、线程并发、事件并发。在这三种模型中，事件并发是最轻量级的，因为多个事件在单个线程中处理，大大减少了线程切换时间，并节省内存。所以采用事件并发模型的NginX/Lighttpd能承受的并发程度最高。

2. 缓存网站内容。有两种情况：1）缓存动态内容的静态结果，加速动态内容；2）在靠客户较近的地方缓存网站内容，节省带宽。

3. 加速动态内容计算。对CPU密集型的动态脚本，缓存opcode，不要每次都解析原始脚本。服务器脚本解析器运行缓存的OpCode，比直接解析原始脚本，效率要高很多。这也是为什么PHP/Python解析引擎需要把原始脚本编译成OpCode，然后再通过虚拟机来解析执行的原因，这样就可以达到和Java、C#差不多的性能。多一道转换，根本原因是为了提升性能。

4. 加速数据库访问。有几种手段：1）增加分布式缓存，缓存查询结果；2）建索引；3）增加DBMS内部查询缓存；4）DBMS内部缓存索引和数据。后两项可通过数据库配置进行。

5. 增加网络带宽。如果网络带宽成为瓶颈，适当增加网络带宽。

逻辑架构如下图所示。

不同的Web内容，因为特性不同，性能瓶颈往往也不同，所需的Web加速策略也不一样。

• 静态内容（小文件）。例如各种图片内容，所需的带宽相对较小。网站处理的瓶颈在IO并发。因此可选用支持事件并发模型的轻量级Web服务器，如NginX/Lighttpd。同时为避免频繁的TCP建立和连接，可打开HTTP协议的KeepAlive长连接功能。这样就存在大量空闲连接，需开启epoll并发模型。同时对更新不频繁的内容，可利用HTTP协议的Last-Modified / If-Modified-Since，ETag / If-None-Match，Expires / Cache-Control等头域协商，在浏览器缓存器内容。

• 静态内容（大文件）。例如各种下载资源，所需带宽大。此时瓶颈往往在带宽，可在靠近客户的地域部署缓存服务器，缓存服务器的缓存策略同样遵守HTTP的头域协商。

• 静态内容（视频）。视频内容往往很大，但用户不追求最高的下载速度，只要能赶上播放速度就行。但是视频延续时间长，从统计学角度看所需带宽很大；而且现在的高清视频，单路视频对带宽要求也很大。所以就近部署的缓存服务器是常有的选择。

• 动态内容。瓶颈在动态计算和数据库，一般实施下列策略：1）缓存opcode；2）加速数据库访问；3）对更新不频繁的动态内容，利用缓存服务器或Web浏览器缓存静态化后的内容。动态内容静态化后往往表现出惊人的并发性能提升效果。

充分考虑网站的内容特征，灵活应用上述加速策略，就能降低服务器/带宽成本，获得最高性价比。

本文出自 “伧夫的博客” 博客，请务必保留此出处http://cangfu.blog.51cto.com/5966711/1574445

谈谈Web加速