将 Web 应用性能提高十倍的10条建议

提高 web 应用的性能从来没有比现在更重要过。 络经济的比重一直在增长；全球经济超过 5% 的价值是在因特 上产生的（数据参见下面的资料）。这个时刻在线的超连接世界意味着用户对其的期望值也处于历史上的最高点。如果你的 站不能及时的响应，或者你的 app 不能无延时的工作，用户会很快的投奔到你的竞争对手那里。

举一个例子，一份亚马逊十年前做过的研究可以证明，甚至在那个时候， 页加载时间每减少100毫秒，收入就会增加1%。另一个最近的研究特别强调一个事实，即超过一半的 站拥有者在调查中承认它们会因为应用程序性能的问题流失用户。

站到底需要多快呢于页面加载，每增加1秒钟就有4%的用户放弃使用。顶级的电子商务站点的页面在第一次交互时可以做到1秒到3秒加载时间，而这是提供最高舒适度的速度。很明显这种利害关系对于 web 应用来说很高，而且在不断的增加。

想要提高效率很简单，但是看到实际结果很难。为了在你的探索之旅上帮助到你，这篇文章会给你提供10条最高可以提升10倍 站性能的建议。这是一系列介绍提高应用程序性能的第一篇文章，包括充分测试的优化技术和一点 NGINX 的帮助。这个系列也给出了潜在的提高安全性的帮助。

NGINX Worker Process helps increase application performance

Tip #2: 添加负载平衡

添加一个负载均衡服务器 是一个相当简单的用来提高性能和 站安全性的的方法。与其将核心 Web 服务器变得越来越大和越来越强，不如使用负载均衡将流量分配到多个服务器。即使程序写的不好，或者在扩容方面有困难，仅是使用负载均衡服务器就可以很好的提高用户体验。

负载均衡服务器首先是一个反向代理服务器（参见Tip #1）——它接受来自互联 的流量，然后转发请求给另一个服务器。特别是负载均衡服务器支持两个或多个应用服务器，使用分配算法将请求转发给不同服务器。最简单的负载均衡方法是轮转法round robin，每个新的请求都会发给列表里的下一个服务器。其它的复制均衡方法包括将请求发给活动连接最少的服务器。NGINX plus 拥有将特定用户的会话分配给同一个服务器的能力。

负载均衡可以很好的提高性能是因为它可以避免某个服务器过载而另一些服务器却没有需要处理的流量。它也可以简单的扩展服务器规模，因为你可以添加多个价格相对便宜的服务器并且保证它们被充分利用了。

可以进行负载均衡的协议包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、 memcached 等，以及几种其它的应用类型，包括基于 TCP 的应用和其它的第4层协议的程序。分析你的 web 应用来决定你要使用哪些以及哪些地方性能不足。

相同的服务器或服务器群可以被用来进行负载均衡，也可以用来处理其它的任务，如 SSL 末端服务器，支持客户端的 HTTP/1.x 和 HTTP/2 请求，以及缓存静态文件。

NGINX 经常被用于进行负载均衡；要想了解更多的情况，可以下载我们的电子书《选择软件负载均衡器的五个理由》。你也可以从 《使用 NGINX 和 NGINX Plus 配置负载均衡，第一部分》中了解基本的配置指导，在 NGINX Plus 管理员指南中有完整的NGINX 负载均衡的文档。。我们的商业版本 NGINX Plus 支持更多优化了的负载均衡特性，如基于服务器响应时间的加载路由和 Microsoft’s NTLM 协议上的负载均衡。

Tip #3: 缓存静态和动态的内容

缓存可以通过加速内容的传输速度来提高 web 应用的性能。它可以采用以下几种策略：当需要的时候预处理要传输的内容，保存数据到速度更快的设备，把数据存储在距离客户端更近的位置，或者将这几种方法结合起来使用。

有两种不同类型数据的缓冲：

• 静态内容缓存。不经常变化的文件，比如图像(JPEG、PNG) 和代码(CSS,JavaScript)，可以保存在外围服务器上，这样就可以快速的从内存和磁盘上提取。
• 动态内容缓存。很多 web 应用会针对每次 页请求生成一个新的 HTML 页面。在短时间内简单的缓存生成的 HTML 内容，就可以很好的减少要生成的内容的数量，而且这些页面足够新，可以满足你的需要。

举个例子，如果一个页面每秒会被浏览10次，你将它缓存 1 秒，90%请求的页面都会直接从缓存提取。如果你分开缓存静态内容，甚至新生成的页面可能都是由这些缓存构成的。

下面由是 web 应用发明的三种主要的缓存技术：

• 缩短数据与用户的 络距离。把一份内容的拷贝放的离用户更近的节点来减少传输时间。
• 提高内容服务器的速度。内容可以保存在一个更快的服务器上来减少提取文件的时间。
• 从过载服务器上移走数据。机器经常因为要完成某些其它的任务而造成某个任务的执行速度比测试结果要差。将数据缓存在不同的机器上可以提高缓存资源和非缓存资源的性能，而这是因为主机没有被过度使用。

对 web 应用的缓存机制可以在 web 应用服务器内部实现。首先，缓存动态内容是用来减少应用服务器加载动态内容的时间。其次，缓存静态内容（包括动态内容的临时拷贝）是为了更进一步的分担应用服务器的负载。而且缓存之后会从应用服务器转移到对用户而言更快、更近的机器，从而减少应用服务器的压力，减少提取数据和传输数据的时间。

改进过的缓存方案可以极大的提高应用的速度。对于大多数 页来说，静态数据，比如大图像文件，构成了超过一半的内容。如果没有缓存，那么这可能会花费几秒的时间来提取和传输这类数据，但是采用了缓存之后不到1秒就可以完成。

举一个在实际中缓存是如何使用的例子， NGINX 和 NGINX Plus 使用了两条指令来设置缓存机制：proxy_cache_path 和 proxy_cache。你可以指定缓存的位置和大小、文件在缓存中保存的最长时间和其它一些参数。使用第三条（而且是相当受欢迎的一条）指令 proxy_cache_use_stale，如果提供新鲜内容的服务器忙碌或者挂掉了，你甚至可以让缓存提供较旧的内容，这样客户端就不会一无所得。从用户的角度来看这可以很好的提高你的 站或者应用的可用时间。

NGINX plus 有个高级缓存特性，包括对缓存清除的支持和在仪表盘上显示缓存状态信息。

要想获得更多关于 NGINX 的缓存机制的信息可以浏览 NGINX Plus 管理员指南中的《参考文档》和《NGINX 内容缓存》。

Tip #4: 压缩数据

压缩是一个具有很大潜力的提高性能的加速方法。现在已经有一些针对照片（JPEG 和PNG）、视频（MPEG-4）和音乐（MP3）等各类文件精心设计和高压缩率的标准。每一个标准都或多或少的减少了文件的大小。

文本数据 —— 包括HTML（包含了纯文本和 HTML 标签），CSS 和代码，比如 Javascript —— 经常是未经压缩就传输的。压缩这类数据会在对应用程序性能的感觉上，特别是处于慢速或受限的移动 络的客户端，产生更大的影响。

这是因为文本数据经常是用户与 页交互的有效数据，而多媒体数据可能更多的是起提供支持或者装饰的作用。智能的内容压缩可以减少 HTML，Javascript，CSS和其它文本内容对带宽的要求，通常可以减少 30% 甚至更多的带宽和相应的页面加载时间。

如果你使用 SSL，压缩可以减少需要进行 SSL 编码的的数据量，而这些编码操作会占用一些 CPU 时间而抵消了压缩数据减少的时间。

压缩文本数据的方法很多，举个例子，在 HTTP/2 中，小说文本的压缩模式就特别调整了头部数据。另一个例子是可以在 NGINX 里打开使用 GZIP 压缩。你在你的服务里预先压缩文本数据之后，你就可以直接使用 gzip_static 指令来处理压缩过的 .gz 版本。

Tip #5: 优化 SSL/TLS

安全套接字（SSL) 协议和它的下一代版本传输层安全（TLS）协议正在被越来越多的 站采用。SSL/TLS 对从原始服务器发往用户的数据进行加密提高了 站的安全性。影响这个趋势的部分原因是 Google 正在使用 SSL/TLS，这在搜索引擎排名上是一个正面的影响因素。

尽管 SSL/TLS 越来越流行，但是使用加密对速度的影响也让很多 站望而却步。SSL/TLS 之所以让 站变的更慢，原因有二：

1. 任何一个连接第一次连接时的握手过程都需要传递密钥。而采用 HTTP/1.x 协议的浏览器在建立多个连接时会对每个连接重复上述操作。
2. 数据在传输过程中需要不断的在服务器端加密、在客户端解密。

web 服务器有对应的机制优化 SSL/TLS 传输。举个例子，NGINX 使用 OpenSSL 运行在普通的硬件上提供了接近专用硬件的传输性能。NGINX 的 SSL 性能 有详细的文档，而且把对 SSL/TLS 数据进行加解密的时间和 CPU 占用率降低了很多。

更进一步，参考这篇文章了解如何提高 SSL/TLS 性能的更多细节，可以总结为一下几点：

• 会话缓冲。使用指令 ssl_session_cache 可以缓存每个新的 SSL/TLS 连接使用的参数。
• 会话票据或者 ID。把 SSL/TLS 的信息保存在一个票据或者 ID 里可以流畅的复用而不需要重新握手。
• OCSP 分割。通过缓存 SSL/TLS 证书信息来减少握手时间。

NGINX 和 NGINX Plus 可以被用作 SSL/TLS 服务端，用于处理客户端流量的加密和解密，而同时以明文方式和其它服务器进行通信。要设置 NGINX 和 NGINX Plus 作为 SSL/TLS 服务端，参看 《HTTPS 连接》 和《加密的 TCP 连接》。

Tip #6: 使用 HTTP/2 或 SPDY

对于已经使用了 SSL/TLS 的站点，HTTP/2 和 SPDY 可以很好的提高性能，因为每个连接只需要一次握手。而对于没有使用 SSL/TLS 的站点来说，从响应速度的角度来说 HTTP/2 和 SPDY 将让迁移到 SSL/TLS 没有什么压力（原本会降低效率）。

Google 在2012年开始把 SPDY 作为一个比 HTTP/1.x 更快速的协议来推荐。HTTP/2 是目前 IETF 通过的标准，是基于 SPDY 的。SPDY 已经被广泛的支持了，但是很快就会被 HTTP/2 替代。

SPDY 和 HTTP/2 的关键是用单一连接来替代多路连接。单个连接是被复用的，所以它可以同时携带多个请求和响应的分片。

通过使用单一连接，这些协议可以避免像在实现了 HTTP/1.x 的浏览器中一样建立和管理多个连接。单一连接在对 SSL 特别有效，这是因为它可以最小化 SSL/TLS 建立安全链接时的握手时间。

SPDY 协议需要使用 SSL/TLS，而 HTTP/2 官方标准并不需要，但是目前所有支持 HTTP/2 的浏览器只有在启用了 SSL/TLS 的情况下才能使用它。这就意味着支持 HTTP/2 的浏览器只有在 站使用了 SSL 并且服务器接收 HTTP/2 流量的情况下才会启用 HTTP/2。否则的话浏览器就会使用 HTTP/1.x 协议。

当你实现 SPDY 或者 HTTP/2 时，你不再需要那些常规的 HTTP 性能优化方案，比如按域分割、资源聚合，以及图像拼合。这些改变可以让你的代码和部署变得更简单和更易于管理。要了解 HTTP/2 带来的这些变化可以浏览我们的《白皮书》。

NGINX Supports SPDY and HTTP/2 for increased web application performance

作为支持这些协议的一个样例，NGINX 已经从一开始就支持了 SPDY，而且大部分使用 SPDY 协议的 站都运行的是 NGINX。NGINX 同时也很早对 HTTP/2 的提供了支持，从2015 年9月开始，开源版 NGINX 和 NGINX Plus 就支持它了。

经过一段时间，我们 NGINX 希望更多的站点完全启用 SSL 并且向 HTTP/2 迁移。这将会提高安全性，同时也会找到并实现新的优化手段，简化的代码表现的会更加优异。

Tip #7: 升级软件版本

一个提高应用性能的简单办法是根据软件的稳定性和性能的评价来选在你的软件栈。进一步说，因为高性能组件的开发者更愿意追求更高的性能和解决 bug ，所以值得使用最新版本的软件。新版本往往更受开发者和用户 区的关注。更新的版本往往会利用到新的编译器优化，包括对新硬件的调优。

稳定的新版本通常比旧版本具有更好的兼容性和更高的性能。一直进行软件更新，可以非常简单的保持软件保持最佳的优化，解决掉 bug，以及提高安全性。

一直使用旧版软件也会阻止你利用新的特性。比如上面说到的 HTTP/2，目前要求 OpenSSL 1.0.1。在2016 年中期开始将会要求1.0.2 ，而它是在2015年1月才发布的。