NGINX应用性能优化指南（第一部分）：时间消耗分析

   <p>【编者的话】本文是“NGINX应用性能优化指南”系列文章的第一篇，主要介绍了如何通过时间消耗分析实现NGINX应用性能优化。</p>    <p> </p>    <h2>正文</h2>    <p>在深入讨论细节之前，我们先考虑下从哪里优化以及为什么优化可能让一个富内容Web应用发生有意义的转变。</p>    <h2>往返时间 （RTT）</h2>    <p>RTT是一个最重要的变量，因为它既能影响延迟，又能影响吞吐量。其影响体现在客户端请求的全部三个阶段：初始连接建立时间、请求-响应延迟和响应正文传送吞吐量。</p>    <p>新建一个HTTPS连接包括DNS查询（通常小于10毫秒）、TCP握手和TLS隧道协商。一旦HTTPS连接建立，每个请求/响应都会（至少）再需要一个RTT。你数一下就会知道，一个新建连接上的单个HTTPS请求最少需要4个RTT：</p>    <p><img src="https://simg.open-open.com/show/454158d387585053551c8bd1afe41db7.png" alt="NGINX应用性能优化指南（第一部分）：时间消耗分析" width="680" height="410"></p>    <p> </p>    <p><strong>注意</strong>：如果要发送的数据大于TCP拥塞窗口，那么可能还需要额外的往返。事实上，要发送的大量初始化数据可能对TCP事务的两个方向均有影响：一方面是客户端请求大小（比如较大的POST），一方面是服务器TLS认证链和服务器响应正文。</p>    <p>最后，不要忘记，TCP吞吐量与RTT是成反比的。其他条件相同的话，<strong>RTT加倍则TCP吞吐量减半</strong>。为此，我们需要考虑源服务器相对于客户端的位置。</p>    <p><img src="https://simg.open-open.com/show/c1d475bd7446a78634b3ec044731877e.png" alt="NGINX应用性能优化指南（第一部分）：时间消耗分析" width="680" height="90"></p>    <p>从美国东海岸到美国西海岸的RTT大约为80毫秒，这是相当可观的。美国东海岸到亚洲的RTT达到了令人厌烦的程度，取决于所用路由的不同，在150毫秒到400毫秒之间。而且，在出现网络拥塞时，端点之间的RTT可能会增加（bufferbloat）并大幅抖动（jitter）。</p>    <p>按照<a href="/misc/goto?guid=4959672363275058184">O’Reilly出版的《高性能浏览器网络》</a>一书的介绍，如果一个应用程序设计供人使用，那么就必须考虑人的时间感知。因此，我们应该竭力在<strong>250毫秒</strong>之内提供可视化反馈，以吸引用户的注意力——既可以是展示静态内容，开始视频播放，也可以是确认行动请求。</p>    <p>另一方面，如果你正在使用CDN，而且它有一个接入点（POP）距离你的终端用户比较近，那么RTT会非常低，大约5到15毫秒。可缓存内容将从CDN边缘节点中获取，浏览器和移动应用可以在动态内容还在从上游获取时就开始渲染，提高了用户感受到的响应性。</p>    <blockquote>     <p>相关教程：<a href="/misc/goto?guid=4959672363360352542">什么是内容缓存？</a></p>    </blockquote>    <p>为了节省同源服务器建立连接的时间，CDN边缘节点通常会保持长连接——同浏览器使用HTTP/1.1头<code>Connection: keep-alive</code>保持长连接是一个意思。事实上，部分CDN甚至提供了一种分层的中间节点层次结构，用于提高持久连接的可扩展性和连接故障。MaxCDN使用<a href="/misc/goto?guid=4959672363445055444">Origin Shield</a>做这件事。</p>    <p>如果你还没有使用CDN，那么你就只能受到源服务器的RTT支配。但是，你可以使用与浏览器和CDN同样的技巧来改善RTT。下面是其中部分技巧：</p>    <ul>     <li>使用构建在移动应用中的静态内容缓存；</li>     <li>让应用同源服务器保持随时可用的连接；</li>     <li>在世界各地部署新的源服务器；</li>     <li>在源服务器中使用具备内容缓存、内容转发和负载均衡特性的NGINX反向代理。</li>    </ul>    <p>Ilya Grigorik的博文“<a href="/misc/goto?guid=4959645759094609764">借助预连接减少往返</a>”是一篇相当不错的文章。虽然本指南主要讨论浏览器和Web应用，但同样的概念可以供移动应用开发人员使用。</p>    <p>此外，从1.9.5版本开始，NGINX提供了HTTP/2支持。这是避免连接建立时间的最好方式，因为HTTP/2在单个隧道中执行所有请求。（额外的好处：不需要修改HTTP/1.1应用程序的语义。）当然，为了充分利用HTTP/2，你必须放弃使用“<a href="/misc/goto?guid=4959672363559302062">域名碎片</a>（domain sharding）”，这是一种绕过浏览器最大端点连接上限的传统技巧。</p>    <h2>请求处理时间（RPT）</h2>    <p>对于简单应用而言，服务器端处理可能很快，但请求需要数百毫秒甚至更长时间才能返回也很常见。取决于请求性质的不同，这可能大相径庭。</p>    <p>脚本和数据库查询优化是容易处理的问题，但应用程序设计优化可能会让你更上一层楼。技巧是寻找方法将阻塞等待变成并行工作。</p>    <p>最后，<strong>单台应用程序服务器不足以支撑繁忙的应用</strong>。随着请求开始排队等待，处理延迟成为衡量响应时间的一个主要部分。这就是为什么在应用程序前面部署一个反向代理会彻底改变游戏规则。它会解锁“超能力”，如负载均衡、内容缓冲、内容转发和“微缓存（micro-caching）”。</p>    <p>总之，如果你能够找到方法解放应用服务器，那么你的时间就花的非常值。让服务器专注于业务逻辑和动态内容生成——就是这样。</p>    <h2>响应传送时间（RDT）</h2>    <p>我将响应传送时间大概定义为应用服务器生成响应以及传送给用户（或者CDN边缘节点）所耗费的时间。</p>    <p>根据我们设定的目标和我们正在构建的应用的类型，我们可以用不同的方式优化RDT。例如，一个文件共享应用可能会将下载周转时间作为关键指标。另一方面，一个实时视频流应用可能会测量向用户传送视频的前10秒所耗费的时间，以便媒体播放器开始播放。</p>    <p>为了改善这些指标，我们应该考虑：1）响应正文的处置和大小；2）响应正文的编码和缓存；3）服务多个用户的吞吐效率和规模效应。</p>    <p>来源：InfoQ</p>