QCon 全球软件开发大会(北京站)门票 9 折倒计时 4 天,点击立减 ¥880 了解详情
写点什么

NGINX 应用性能优化指南(第一部分):时间消耗分析

2016 年 4 月 13 日

【编者的话】本文是“NGINX 应用性能优化指南”系列文章的第一篇,主要介绍了如何通过时间消耗分析实现 NGINX 应用性能优化。

注:本文最初发布于 MaxCDN 博客,InfoQ 中文站在获得作者授权的基础上对文章进行了翻译。

正文

在深入讨论细节之前,我们先考虑下从哪里优化以及为什么优化可能让一个富内容 Web 应用发生有意义的转变。

往返时间 (RTT)

RTT 是一个最重要的变量,因为它既能影响延迟,又能影响吞吐量。其影响体现在客户端请求的全部三个阶段:初始连接建立时间、请求 - 响应延迟和响应正文传送吞吐量。

新建一个 HTTPS 连接包括 DNS 查询(通常小于 10 毫秒)、TCP 握手和 TLS 隧道协商。一旦 HTTPS 连接建立,每个请求 / 响应都会(至少)再需要一个 RTT。你数一下就会知道,一个新建连接上的单个 HTTPS 请求最少需要 4 个 RTT:

注意:如果要发送的数据大于 TCP 拥塞窗口,那么可能还需要额外的往返。事实上,要发送的大量初始化数据可能对 TCP 事务的两个方向均有影响:一方面是客户端请求大小(比如较大的 POST),一方面是服务器 TLS 认证链和服务器响应正文。

最后,不要忘记,TCP 吞吐量与 RTT 是成反比的。其他条件相同的话,RTT 加倍则 TCP 吞吐量减半。为此,我们需要考虑源服务器相对于客户端的位置。

从美国东海岸到美国西海岸的 RTT 大约为 80 毫秒,这是相当可观的。美国东海岸到亚洲的 RTT 达到了令人厌烦的程度,取决于所用路由的不同,在 150 毫秒到 400 毫秒之间。而且,在出现网络拥塞时,端点之间的 RTT 可能会增加(bufferbloat)并大幅抖动(jitter)。

按照 O’Reilly 出版的《高性能浏览器网络》一书的介绍,如果一个应用程序设计供人使用,那么就必须考虑人的时间感知。因此,我们应该竭力在250 毫秒之内提供可视化反馈,以吸引用户的注意力——既可以是展示静态内容,开始视频播放,也可以是确认行动请求。

另一方面,如果你正在使用 CDN,而且它有一个接入点(POP)距离你的终端用户比较近,那么 RTT 会非常低,大约 5 到 15 毫秒。可缓存内容将从 CDN 边缘节点中获取,浏览器和移动应用可以在动态内容还在从上游获取时就开始渲染,提高了用户感受到的响应性。

相关教程:什么是内容缓存?

为了节省同源服务器建立连接的时间,CDN 边缘节点通常会保持长连接——同浏览器使用 HTTP/1.1 头Connection: keep-alive保持长连接是一个意思。事实上,部分 CDN 甚至提供了一种分层的中间节点层次结构,用于提高持久连接的可扩展性和连接故障。MaxCDN 使用 Origin Shield 做这件事。

如果你还没有使用 CDN,那么你就只能受到源服务器的 RTT 支配。但是,你可以使用与浏览器和 CDN 同样的技巧来改善 RTT。下面是其中部分技巧:

  • 使用构建在移动应用中的静态内容缓存;
  • 让应用同源服务器保持随时可用的连接;
  • 在世界各地部署新的源服务器;
  • 在源服务器中使用具备内容缓存、内容转发和负载均衡特性的 NGINX 反向代理。

Ilya Grigorik 的博文“借助预连接减少往返”是一篇相当不错的文章。虽然本指南主要讨论浏览器和Web 应用,但同样的概念可以供移动应用开发人员使用。

此外,从1.9.5 版本开始,NGINX 提供了HTTP/2 支持。这是避免连接建立时间的最好方式,因为HTTP/2 在单个隧道中执行所有请求。(额外的好处:不需要修改HTTP/1.1 应用程序的语义。)当然,为了充分利用HTTP/2,你必须放弃使用“域名碎片(domain sharding)”,这是一种绕过浏览器最大端点连接上限的传统技巧。

请求处理时间(RPT)

对于简单应用而言,服务器端处理可能很快,但请求需要数百毫秒甚至更长时间才能返回也很常见。取决于请求性质的不同,这可能大相径庭。

脚本和数据库查询优化是容易处理的问题,但应用程序设计优化可能会让你更上一层楼。技巧是寻找方法将阻塞等待变成并行工作。

最后,单台应用程序服务器不足以支撑繁忙的应用。随着请求开始排队等待,处理延迟成为衡量响应时间的一个主要部分。这就是为什么在应用程序前面部署一个反向代理会彻底改变游戏规则。它会解锁“超能力”,如负载均衡、内容缓冲、内容转发和“微缓存(micro-caching)”。

总之,如果你能够找到方法解放应用服务器,那么你的时间就花的非常值。让服务器专注于业务逻辑和动态内容生成——就是这样。

响应传送时间(RDT)

我将响应传送时间大概定义为应用服务器生成响应以及传送给用户(或者CDN 边缘节点)所耗费的时间。

根据我们设定的目标和我们正在构建的应用的类型,我们可以用不同的方式优化RDT。例如,一个文件共享应用可能会将下载周转时间作为关键指标。另一方面,一个实时视频流应用可能会测量向用户传送视频的前10 秒所耗费的时间,以便媒体播放器开始播放。

为了改善这些指标,我们应该考虑:1)响应正文的处置和大小;2)响应正文的编码和缓存;3)服务多个用户的吞吐效率和规模效应。

查看英文原文: NGINX Application Performance Optimization:Time Spent Analysis


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 4 月 13 日 17:576046
用户头像

发布了 1008 篇内容, 共 314.9 次阅读, 收获喜欢 283 次。

关注

评论

发布
暂无评论
发现更多内容

广西党建智慧平台方案,智慧组工信息化建设

135深圳3055源中瑞8032

话题讨论 |互联网软件技术培训,靠谱吗?

不脱发的程序猿

程序员 程序人生 话题讨论 互联网培训 技术培训

大作业1-同城快递业务系统设计

arcyao

阿里架构师经验分享!写给互联网大厂员工的真心话,最全的BAT大厂面试题整理

欢喜学安卓

android 程序员 面试 移动开发

从零开始学Android!15个经典面试问题及回答思路,这原因我服了

欢喜学安卓

android 程序员 面试 移动开发

如何制作和使用自签名证书

soulteary

Docker SSL证书

即使技术再精,面试时一问这个必挂!!

冰河

面试 类加载器 我要进大厂 Java类加载

Python实现钉钉/企业微信自动打卡

sum56

Python python 爬虫 打卡

架构师训练营结课作业

Rocky·Chen

期末大作业一

心在那片海

OpenCV简介及其工程应用-游戏色块检测

行者AI

OpenCV

智慧组工系统开发解决方案,组织部干部管理平台搭建

WX13823153201

智慧组工系统开发

大作业2-知识总结

arcyao

重磅发布 | 2021年OpenAtom XuperChain开源技术路径

开放原子开源基金会

区块链 百度 开源 开放原子开源基金会

百度网盘限速解决方案

孙叫兽

解决方案 百度网盘 限速

使用APICloud敏捷式开发总结,回顾开发一个完整APP过程。

孙叫兽

App 开发 APICloud

婚恋交友软件开发

luluhulian

期末大作业二

心在那片海

复盘银行的区块链实践:从分布式账本,到产业数字化

CECBC区块链专委会

银行 银行大数据

“五年饮冰,难凉热血”,一名专科生的求学历程

不脱发的程序猿

程序人生 心路历程 2月春节不断更 大学总结 2020年度总结

学习总结之HTML5剑指前端(建议收藏,图文并茂)

魔王哪吒

学习 程序员 面试 前端 2月春节不断更

驱动力读书笔记之四

张老蔫

28天写作

2020年末总结,脚踏实地,一步一个脚印——致敬自己一年的心酸历程

孙叫兽

孙叫兽 年度报告

区块链珠宝溯源平台,区块链溯源解决方案

135深圳3055源中瑞8032

史上最全的技术手册整理总结,编程小白都从这篇文章迅速成为大牛

孙叫兽

Java 前端 技术手册 开发文档

让人“眼前一亮、不明觉厉”的互联网技术PPT

不脱发的程序猿

程序人生 PPT 2月春节不断更 互联网技术PPT 互联网工具

智慧社区服务平台,平安社区搭建

135深圳3055源中瑞8032

程序员养家活口接私活必备网站(顺便用技术改变世界)

孙叫兽

程序员 网站 私活

股票配资系统开发

v16629866266

Elasticsearch multi-index 搜索

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

产品 0 期 - 第四周作业

vipyinzhiwei

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

NGINX应用性能优化指南(第一部分):时间消耗分析-InfoQ