大型网站性能优化实战:从前端.网络.CDN到后端.大促的全链路性能优化详解

√ 近十年阿里技术架构师的实践总结 √ 一套完整的、体系化的大型网站性能优化方法论 √ 一个端到端、完整的性能优化解决方案 √ 可直接用于指导PV十亿级网站的性能优化 √ 可帮助技术团队建立全局性能分析、监控和调优方案 √ 可实现用较小的技术成本换得更好的系统性能 √ 对电商网站架构规划、社交网站性能调优、移动互联网和物联网通信架构的性能优化都有实际的参考价值 √ 从Web前端到服务端，从外部链路到内部机房，沉淀了大量的全链路性能问题分析思路和实战解决方案 √ 本书三位作者分别为阿里不错技术专家、蚂蚁金服集团不错架构师和速卖通前端性能专家

性能是大型网站的一个要素，影响性能的因素很好多。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》由三位熟悉不同领域性能优化的技术专家打造，从大型网站的整体体系出发，讲述大型网站性能优化的全链路实践过程，包括核心原理、常见策略与实战案例。具体内容包括：基于用户体验的性能优化要素、前端性能优化实战、网站性能分析、服务端性能优化、TCP优化、DNS优化、CDN优化、大型网站性能监控体系、大型网站容量评估、高性能系统架构模式、大促保障体系、数据分析驱动性能优化。 《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》的初衷就是将实践经验分享给读者，展示性能优化相关知识的全貌。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》中的很多性能优化方法和策略都是作者从实践中总结出来的，实用性很好强。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》既可供入门者了解大型网站性能优化所有的相关技术，以及解决问题的思路和方法，也可供业界同行参考，给日常工作带来启发。

周涛明，阿里不错技术专家、本书的倡导者，在阿里体系有6年的工作经历，见证了阿里的某个电子商务平台从小到大的发展历程，过多次大促总体负责的工作。之前在Cisco工作，在阿里速卖通负责性能领域工作，参与过CDN、TCP、DNS的优化工作，特别是对CDN有比较深入的了解，对服务器端性能优化有比较多的经验，曾在蚂蚁金服保险事业部主要负责平台保险的架构工作，目前在集团信息平台事业部做架构师。 张荣华，蚂蚁金服集团不错架构师，有12年工作经验，曾在土豆网从事架构工作，是Javaeye的资深撰稿人，他写的很多文章在Javaeye里引起了很大反响。在阿里从事多年架构工作，多次和笔者搭档历经大促性能保障工作，同时有很好丰富的性能优化经验，对架构、领域模型、性能等多方面都有很好丰富的经验，很好擅于学习，在计算机领域是的人才，同时解决了很多难题。他的特点是，能将一个技术难题深入浅出地分析到位，是很好擅于讲故事的同学，是一位真正的技术人。 张新兵，速卖通前端性能专家，对于前端的性能优化有很好丰富的经验，从他身上能够看到技术人员不折不挠的钻研精神。让人印象深刻的是，为了解决兼容SEO的问题，他提出了页面不能异步化加载的前端性能优化方案，从方案提出到落地，经历了很长的时间与各部门业务同事沟通、反复试验，效果喜人。

第1章 基于用户体验的性能优化要素 1 1.1 页面用户体验的要素介绍 1 1.2 白屏时间 3 1.2.1 白屏时间的重要性 3 1.2.2 白屏过程详解 4 1.3 首屏时间 10 1.3.1 首屏时间的定义 10 1.3.2 首屏时间的重要性 11 1.4 页面整体加载完成 15 第2章 前端性能优化实战 16 2.1 延迟渲染 16 2.1.1 挑战和困难 17 2.1.2 解决方案 17 2.2 SEO Ajax 20 2.2.1 挑战和困难 21 2.2.2 解决方案 21 第3章 网站性能分析 24 3.1 快速了解网站性能 24 3.1.1 使用YSlow进行性能分析 24 3.1.2 使用PageSpeed进行性能分析 25 3.1.3 使用WebPagetest进行性能分析 27 3.2 真实用户前端性能监控 29 3.2.1 真实用户前端性能数据采集 29 3.2.2 数据采集可行性分析 30 第4章 服务端性能优化 36 4.1 优选QPS推算及验证 36 4.1.1 RT 37 4.1.2 单线程QPS 38 4.1.3 很好线程数 38 4.1.4 优选QPS 39 4.1.5 实验数据验证公式 44 4.1.6 压力测试很好线程数和QPS的临界点 47 4.2 同步模型与异步模型 49 4.2.1 同步模型 49 4.2.2 异步模型 50 4.2.3 为什么异步模型需要的线程数少 58 4.2.4 两个模型的对比及异步模型适用场景 59 4.2.5 小结 60 4.3 数据结构对性能的影响 61 4.3.1 HashMap的问题 61 4.3.2 HashMap的结构 62 4.3.3 碰撞 64 4.3.4 Hash算法 65 4.3.5 题外话：ConcurrentHashMap中的Hash 72 4.3.6 HashMap综述 73 4.3.7 均摊 74 4.4 算法设计不合理带来的性能问题 78 4.4.1 某应用A的现象 78 4.4.2 某应用B的现象 78 4.4.3 分析 79 4.4.4 方案 81 4.4.5 验证 82 4.4.6 小结 86 4.5 综合案例：电商活动页面性能优化 86 4.5.1 第一轮：通过APC使QPS提高近3倍 86 4.5.2 第二轮：解决消耗CPU资源大户Gzip 92 4.5.3 小结 105 第5章 TCP优化 107 5.1 TCP传输原理 108 5.1.1 TCP传输的简要说明 108 5.1.2 滑动窗口——接收端流量控制 108 5.1.3 拥塞窗口——发送端流量控制 109 5.1.4 传统TCP拥塞控制问题 110 5.2 Linux内核升级中的TCP优化技术 110 5.2.1 调整接收窗口 111 5.2.2 初始拥塞窗口调整（Linux 2.6.38开始支持） 111 5.2.3 Early Retransmit（Linux 3.5开始支持） 112 5.2.4 初始RTO调整（Linux 2.6.18开始支持） 114 5.2.5 TFO 114 5.2.6 TSO 115 5.3 TIME_WAIT问题案例分析 116 5.3.1 问题现象 116 5.3.2 问题分析 117 5.3.3 问题初步解决 118 5.3.4 问题再分析 118 5.3.5 问题后记 119 5.4 总结 119 第6章 DNS优化 120 6.1 DNS基本原理 121 6.1.1 DNS的一些关键术语 121 6.1.2 DNS查询过程 122 6.1.3 NS选择策略和机制 124 6.1.4 DNS扩展协议EDNS 125 6.1.5 常用DNS相关命令 126 6.2 实战案例：超远距离DNS性能问题分析和优化 130 6.2.1 现象描述 130 6.2.2 DNS Lookup耗时长的问题分析 131 6.2.3 DNS解析性能解决方案 133 6.3 总结 136 第7章 CDN优化 138 7.1 CDN优化概述 138 7.2 CDN的相关术语 140 7.3 从应用看CDN的基本原理 141 7.3.1 CDN基本架构 141 7.3.2 CDN全局调度 141 7.3.3 CDN基本调度方式 142 7.3.4 CDN加速的基本实施流程 145 7.4 CDN优化常见策略 146 7.4.1 静态化缓存优化 146 7.4.2 动态内容静态边缘化 147 7.4.3 动态加速优化 150 7.4.4 用户序列优化原理 153 7.4.5 域名合并优化 153 7.4.6 多级缓存架构优化 154 7.4.7 301、302跳转边缘化访问和多终端边缘化判断 154 7.5 CDN优化实战 155 7.5.1 CDN的不合理架构造成304请求耗时长优化实战 155 7.5.2 静态资源命中率优化实战 159 7.5.3 CDN动态加速优化实战 164 7.5.4 CDN静态化的问题和优化实战 171 7.5.5 CDN调度优化实战 178 7.6 总结 179 第8章 大型网站性能监控体系 182 8.1 监控设计 183 8.1.1 应用监控存在的问题 183 8.1.2 从问题排查思路看监控的设计 183 8.1.3 监控的设计步骤 184 8.1.4 监控常见法则总结 187 8.2 大型网站性能监控体系设计目标和原则 188 8.2.1 准确性 188 8.2.2 完整性 189 8.2.3 实时性 189 8.2.4 细分化 189 8.2.5 聚合化 189 8.2.6 图表化 190 8.2.7 可追溯 190 8.3 性能指标和监控项及实现 190 8.4 性能监控的关键指标 194 8.4.1 应用监控 194 8.4.2 系统监控 196 8.5 常用监控命令详解 201 第9章 大型网站容量评估 205 9.1 容量评估概述 205 9.2 容量评估的特点 206 9.3 单机峰值QPS的测算 206 9.3.1 单机测算方法 207 9.3.2 两种常用的引流压力测试方法 207 9.3.3 引流压力测试停止时间的判断 208 9.3.4 如何避免单机压力测试出现问题 209 9.4 大型网站常用的容量评估方法 210 9.4.1 二八原则评估法——新业务评估的基本方法 210 9.4.2 有历史数据参考的容量评估——GMV线性比例评估法和GMV转化评估法 210 9.4.3 流量占比评估法 215 9.5 总结 216 第10章 高性能系统架构模式 218 10.1 无状态架构 219 10.1.1 解决方案一——Session复制 219 10.1.2 解决方案二——Session Sticky 220 10.1.3 解决方案三——Session集中式存储 220 10.1.4 解决方案四——基于浏览器Cookie的无状态架构 222 10.2 基于负载均衡器的水平扩展架构 222 10.3 基于DNS的负载均衡 224 10.4 读写分离架构 224 10.5 基于数据水平切分的水平扩展架构 225 10.6 缓存架构 228 10.6.1 缓存的基本属性 229 10.6.2 缓存的分类 229 10.6.3 缓存使用常见的问题和误区 230 10.6.4 缓存使用场景 231 10.6.5 缓存使用规范和原则 232 10.7 近端架构 233 10.8 异步化架构 234 10.9 排队缓冲架构 235 10.10 多机房架构 236 10.10.1 同城架构 236 10.10.2 异地架构 238 10.11 基于服务的可扩展架构 240 10.12 日结架构 242 10.13 热点避免架构 243 第11章 大促保障体系 246 11.1 大促保障概述 246 11.1.1 大促保障简介 246 11.1.2 大促保障整体流程 247 11.2 大促保障体系详解 249 11.2.1 容量保障体系 249 11.2.2 风险保障体系 253 11.2.3 组织保障 255 11.2.4 运维保障 255 11.2.5 中间件保障 256 11.3 大促容量峰值保障策略 257 11.4 大促风险保障策略 259 11.4.1 风险保障概述 259 11.4.2 风险保障常见风险 259 11.4.3 风险识别和风险分类 260 11.4.4 风险保障策略 263 11.4.5 分组隔离策略 265 11.4.6 业务降级策略 265 11.4.7 监控发现策略 265 11.5 大促资金安全保障策略 265 11.5.1 常见的资金安全防护策略 265 11.5.2 大促资金安全防护 268 11.6 大促经验沉淀 268 11.7 大促保障实战分析 269 11.7.1 机房网络瓶颈问题分析 269 11.7.2 集群个体异常造成的容量问题分析 275 11.7.3 诡异的网络瓶颈 278 11.7.4 多机房压力测试流量不均问题分析 283 11.7.5 Tengine限流案例 291 11.8 总结 292 第12章 数据分析驱动性能优化 293 12.1 WebP性能优化案例背景 293 12.1.1 WebP格式开始兴起 294 12.1.2 WebP改造使L-D转化率下降 295 12.2 性能优化中的数据分析原理与方法 296 12.2.1 数据分析简介 296 12.2.2 数据分析之杜邦分析 297 12.2.3 数据分析之多维分析 299 12.3 通过数据分析来诊断WebP的性能问题 303 12.3.1 指标定义 303 12.3.2 基于指标树自动诊断WebP的性能问题 305 12.4 案例：通过数据分析进行OLAP分析和RT优化 308 12.4.1 在线分析系统响应指标基线的定义 308 12.4.2 性能问题诊断 309 12.4.3 数据的获取及觉察 311 12.4.4 方案的推导 313 12.4.5 小结 315 12.5 通过函数抽象进行性能优化 316 12.5.1 优化过程简介 316 12.5.2 函数抽象 317 12.5.3 统计分析 319 12.5.4 小结 321

    对于像淘宝这样规模网站的主域名，TTL设置可以短一点，对于大型网站，异地容灾基本都是标配，一旦机房A出现问题，就将域名解析的A地址从地区A的虚拟IP切换到地区B的虚拟IP，这样能够起到异地容灾的作用，大大提高系统的稳定性。所以对于笔者曾经所在业务的主域名，由于网站规模较大，TTL时间并没有调整，保持10分钟不变。 对于静态资源相关的域名，跨境优选化网站的CDN解析路径比较长，这有客观原因，海外CDN目前可能是多个CDN厂商共存的状态，各CDN厂商在优选的部署节点数有所不同，服务优势有差异。首先要CNAME给CDN提供商A的解析服务器（其目的是根据国家来确定是否CNAME给该CDN厂商进行静态加速），再由AliCDN的解析服务器决定是否CNAME给Akamai的全局调度解析器。CNAME的TTL时间设置过短会导致一次完整的DNS的递归查询，需要多个RTT往返，这对于跨境优选化网站的性能而言是一场灾难。 笔者所在跨境电商网站早期将CDN相关的靠前层CNAME时间全部改成了1小时，DNS Lookup抖动小了很多。靠前层CNAME的TTL改长，那么在设定的TTL内，gtms01.alicdn. com.danuoyi.tbcache.com这一层的域名解析可以省掉，Local DNS可以直接通过Local DNS缓存的IP地址访问gtms01.alicdn.com.danuoyi.tbcache.com.的非常不错DNS。但是从下面仍然可以看到第二层、第三层的CNAME的TTL时间还是有点短，个人觉得还可以调整至更长时间，特别是第三层，从解析层次上来看，DNS完整的查询时间在很差的情况下可能需要数十个RTT往返，所以几秒钟就正常了。参考代码如下。 gtms01.alicdn.com.3600 IN CNAME gtms01.alicdn.com.danuoyi.tbcache.com. gtms01.alicdn.com.danuoyi.tbcache.com.1800 IN CNAME piscestms01.danuoyi. tbcache.com. piscestms01.danuoyi.tbcache.com. 300 IN CNAME gtms.alicdn.com. edgesuite.net.gtms.alicdn.com.edgesuite.net.21600 IN CNAME a1049.g. akamai. net. a1049.g.akamai.net.20 IN A 128.241.216.194 a1049.g.akamai.net.20 IN A 128.241.216.154 2．DNS多点就近部署架构升级 TTL时间的调整能够大幅减少用户所在的Local DNS到非常不错DNS的往返时间，但是TTL时间一旦过期，特别是有些层次的TTL时间无法变得更长时（如高可用性要求）。非常不错DNS的多点部署很好关键，域名解析原理看起来比较简单，但在实际使用过程中会有很好多的CNAME，每一次CNAME都有一次完整的域名解析请求，需要数个RTT才能完成。gtms01.alicdn.com域名的非常不错DNS开始只在靠前有，为了优化AliCDN相关域名的DNS解析性能，笔者做了两件事情。 靠前件事情是对非常不错NS的变更。把alicdn.com的非常不错NS，从靠前改成AliExpress主域名的NS，变更之前如下： alicdn.com. 172800 IN NS ns5.aliyun.com. alicdn.com. 172800 IN NS ns4.aliyun.com. alicdn.com. 172800 IN NS ns3.aliyun.com. 变更之后如下： ;; ANSWER SECTION: alicdn.com. 172800 IN NS nshz.alibabaonline.com. alicdn.com. 172800 IN NS nsp.alibabaonline.com. alicdn.com. 172800 IN NS ns8.alibabaonline.com. alicdn.com. 172800 IN NS nsp2.alibabaonline.com. 第二件事情是在taocache.com（AliExpress静态域名相关的调度解析服务器）的NS下面挂了一个新的美国的IP地址，大家知道Local DNS现在已经很智能了，可以就近选择一个NS地址，这就是利用DNS的多点就近部署架构来解决DNS的性能问题。