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

√ 近十年阿里技术架构师的实践总结

√ 一套完整的、体系化的大型网站性能优化方法论

√ 一个端到端、完整的性能优化解决方案

√ 可直接用于指导PV十亿级网站的性能优化

√ 可帮助技术团队建立全局性能分析、监控和调优方案

√ 可实现用较小的技术成本换得更好的系统性能

√ 对电商网站架构规划、社交网站性能调优、移动互联网和物联网通信架构的性能优化都有实际的参考价值

√ 从Web前端到服务端，从外部链路到内部机房，沉淀了大量的全链路性能问题分析思路和实战解决方案

√ 本书三位作者分别为阿里高级技术专家、蚂蚁金服集团高级架构师和速卖通前端性能专家

性能是大型网站的一个要素，影响性能的因素非常多。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》由三位熟悉不同领域性能优化的技术专家打造，从大型网站的整体体系出发，讲述大型网站性能优化的全链路实践过程，包括核心原理、常见策略与实战案例。具体内容包括：基于用户体验的性能优化要素、前端性能优化实战、网站性能分析、服务端性能优化、TCP优化、DNS优化、CDN优化、大型网站性能监控体系、大型网站容量评估、高性能系统架构模式、大促保障体系、数据分析驱动性能优化。

《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》的初衷就是将实践经验分享给读者，展示性能优化相关知识的全貌。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》中的很多性能优化方法和策略都是作者从实践中总结出来的，实用性非常强。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》既可供入门者了解大型网站性能优化所有的相关技术，以及解决问题的思路和方法，也可供业界同行参考，给日常工作带来启发。

周涛明，阿里高级技术专家、本书的倡导者，在阿里体系有6年的工作经历，见证了阿里的某个电子商务平台从小到大的发展历程，主导过多次大促总体负责的工作。之前在Cisco工作，在阿里速卖通负责性能领域工作，参与过CDN、TCP、DNS的优化工作，特别是对CDN有比较深入的了解，对服务器端性能优化有比较多的经验，曾在蚂蚁金服保险事业部主要负责平台保险的架构工作，目前在集团信息平台事业部做架构师。

张荣华，蚂蚁金服集团大数据洞察平台架构师&TL，曾在土豆网从事架构工作，javaeye资深撰稿人，也是阿里内部技术论坛的撰稿人，他写的很多文章都引起了很大的反响。在阿里多年从事架构工作，多次和笔者搭档经历大促性能保障工作，有非常丰富的性能优化经验，对互联网架构，领域建模，性能等很多方面都有非常丰富的经验。非常擅于学习，同时解决了很多技术难题。他的特点是，能将一个技术难题深入浅出地分析到位，非常擅于讲故事，是一位真正的技术人。

张新兵，速卖通前端性能专家，对于前端的性能优化有非常丰富的经验，从他身上能够看到技术人员不折不挠的钻研精神。让人印象深刻的是，为了解决兼容SEO的问题，他提出了页面不能异步化加载的前端性能优化方案，从方案提出到落地，经历了很长的时间与各部门业务同事沟通、反复试验，效果喜人。

作者在阿里近十年的技术架构师实践中，总结出了一套体系化的大型网站性能优化方法论，又经过一年多时间方成此书。这个性能优化的技术体系是端到端的完整性能解决方案，可直接用于指导PV十亿级网站的性能优化，可帮助技术团队建立全局性能分析、监控和调优方案，可实现用较小的技术成本换得更好的系统性能。本书对于电商网站架构规划、社交网站性能调优、移动互联网和物联网通信架构的性能优化都有实际的参考价值。作者本人与我在阿里共事近8年，一起经历了一个网站从小到大的过程，其全面的技术解题视角，深入协议层的技术攻关能力，对于技术创造商业价值的思考，都可以在书中感受到。
• 阿里资深总监 叶军（不穷）


大型分布式网站在高速发展的过程中，整体系统容量和用户体验的性能调优至关重要，笔者以在阿里负责全球速卖通网站性能优化架构演进的亲身经历，从Web前端到服务端，从外部链路到内部机房，沉淀了大量的全链路性能问题分析思路和实战解决方案，非常值得一阅！
• 蚂蚁金服资深技术专家 雷继斌（雷舍）


涛明是我认识多年的合作伙伴，经常发现他对于细节都有寻根刨底的特质，对于大型网站架构、网站性能优化、CDN的使用，都可以做到从底层到上层全局的把控。如果你想真正把网站性能消耗的来龙去脉都理清楚，本书是非常好的从入门到精通的书籍，建议应用开发工程师都来读一下。
• 阿里云CDN资深技术专家 文景

第1章基于用户体验的性能优化要素

1.1 页面用户体验的要素介绍

1.2 白屏时间

1.2.1 白屏时间的重要性

1.2.2 白屏过程详解

1.3 首屏时间

1.3.1 首屏时间的定义

1.3.2 首屏时间的重要性

1.4 页面整体加载完成

第2章前端性能优化实战

2.1 延迟渲染

2.1.1 挑战和困难

2.1.2 解决方案

2.2 SEO Ajax

2.2.1 挑战和困难

2.2.2 解决方案

第3章网站性能分析

3.1 快速了解网站性能

3.1.1 使用YSlow进行性能分析

3.1.2 使用PageSpeed进行性能分析

3.1.3 使用WebPagetest进行性能分析

3.2 真实用户前端性能监控

3.2.1 真实用户前端性能数据采集

3.2.2 数据采集可行性分析

第4章服务端性能优化

4.1 最大QPS推算及验证

4.1.1 RT

4.1.2 单线程QPS

4.1.3 最佳线程数

4.1.4 最大QPS

4.1.5 实验数据验证公式

4.1.6 压力测试最佳线程数和QPS的临界点

4.2 同步模型与异步模型

4.2.1 同步模型

4.2.2 异步模型

4.2.3 为什么异步模型需要的线程数少

4.2.4 两个模型的对比及异步模型适用场景

4.2.5 小结

4.3 数据结构对性能的影响

4.3.1 HashMap的问题

4.3.2 HashMap的结构

4.3.3 碰撞

4.3.4 Hash算法

4.3.5 题外话：ConcurrentHashMap中的Hash

4.3.6 HashMap综述

4.3.7 均摊

4.4 算法设计不合理带来的性能问题

4.4.1 某应用A的现象

4.4.2 某应用B的现象

4.4.3 分析

4.4.4 方案

4.4.5 验证

4.4.6 小结

4.5 综合案例：电商活动页面性能优化

4.5.1 第一轮：通过APC使QPS提高近3倍

4.5.2 第二轮：解决消耗CPU资源大户Gzip

4.5.3 小结

第5章TCP优化

5.1 TCP传输原理

5.1.1 TCP传输的简要说明

5.1.2 滑动窗口——接收端流量控制

5.1.3 拥塞窗口——发送端流量控制

5.1.4 传统TCP拥塞控制问题

5.2 Linux内核升级中的TCP优化技术

5.2.1 调整接收窗口

5.2.2 初始拥塞窗口调整（Linux 2.6.38开始支持）

5.2.3 Early Retransmit（Linux 3.5开始支持）

5.2.4 初始RTO调整（Linux 2.6.18开始支持）

5.2.5 TFO

5.2.6 TSO

5.3 TIME_WAIT问题案例分析

5.3.1 问题现象

5.3.2 问题分析

5.3.3 问题初步解决

5.3.4 问题再分析

5.3.5 问题后记

5.4 总结

第6章DNS优化

6.1 DNS基本原理

6.1.1 DNS的一些关键术语

6.1.2 DNS查询过程

6.1.3 NS选择策略和机制

6.1.4 DNS扩展协议EDNS

6.1.5 常用DNS相关命令

6.2 实战案例：超远距离DNS性能问题分析和优化

6.2.1 现象描述

6.2.2 DNS Lookup耗时长的问题分析

6.2.3 DNS解析性能解决方案

6.3 总结

第7章CDN优化

7.1 CDN优化概述

7.2 CDN的相关术语

7.3 从应用看CDN的基本原理

7.3.1 CDN基本架构

7.3.2 CDN全局调度

7.3.3 CDN基本调度方式

7.3.4 CDN加速的基本实施流程

7.4 CDN优化常见策略

7.4.1 静态化缓存优化

7.4.2 动态内容静态边缘化

7.4.3 动态加速优化

7.4.4 用户序列优化原理

7.4.5 域名合并优化

7.4.6 多级缓存架构优化

7.4.7 301、302跳转边缘化访问和多终端边缘化判断

7.5 CDN优化实战

7.5.1 CDN的不合理架构造成304请求耗时长优化实战

7.5.2 静态资源命中率优化实战

7.5.3 CDN动态加速优化实战

7.5.4 CDN静态化的问题和优化实战

7.5.5 CDN调度优化实战

7.6 总结

第8章大型网站性能监控体系

8.1 监控设计

8.1.1 应用监控存在的问题

8.1.2 从问题排查思路看监控的设计

8.1.3 监控的设计步骤

8.1.4 监控常见法则总结

8.2 大型网站性能监控体系设计目标和原则

8.2.1 准确性

8.2.2 完整性

8.2.3 实时性

8.2.4 细分化

8.2.5 聚合化

8.2.6 图表化

8.2.7 可追溯

8.3 性能指标和监控项及实现

8.4 性能监控的关键指标

8.4.1 应用监控

8.4.2 系统监控

8.5 常用监控命令详解

第9章大型网站容量评估

9.1 容量评估概述

9.2 容量评估的特点

9.3 单机峰值QPS的测算

9.3.1 单机测算方法

9.3.2 两种常用的引流压力测试方法

9.3.3 引流压力测试停止时间的判断

9.3.4 如何避免单机压力测试出现问题

9.4 大型网站常用的容量评估方法

9.4.1 二八原则评估法——新业务评估的基本方法

9.4.2 有历史数据参考的容量评估——GMV线性比例评估法和GMV转化评估法

9.4.3 流量占比评估法

9.5 总结

第10章高性能系统架构模式

10.1 无状态架构

10.1.1 解决方案一——Session复制

10.1.2 解决方案二——Session Sticky

10.1.3 解决方案三——Session集中式存储

10.1.4 解决方案四——基于浏览器Cookie的无状态架构

10.2 基于负载均衡器的水平扩展架构

10.3 基于DNS的负载均衡

10.4 读写分离架构

10.5 基于数据水平切分的水平扩展架构

10.6 缓存架构

10.6.1 缓存的基本属性

10.6.2 缓存的分类

10.6.3 缓存使用常见的问题和误区

10.6.4 缓存使用场景

10.6.5 缓存使用规范和原则

10.7 近端架构

10.8 异步化架构

10.9 排队缓冲架构

10.10 多机房架构

10.10.1 同城架构

10.10.2 异地架构

10.11 基于服务的可扩展架构

10.12 日结架构

10.13 热点避免架构

第11章大促保障体系

11.1 大促保障概述

11.1.1 大促保障简介

11.1.2 大促保障整体流程

11.2 大促保障体系详解

11.2.1 容量保障体系

11.2.2 风险保障体系

11.2.3 组织保障

11.2.4 运维保障

11.2.5 中间件保障

11.3 大促容量峰值保障策略

11.4 大促风险保障策略

11.4.1 风险保障概述

11.4.2 风险保障常见风险

11.4.3 风险识别和风险分类

11.4.4 风险保障策略

11.4.5 分组隔离策略

11.4.6 业务降级策略

11.4.7 监控发现策略

11.5 大促资金安全保障策略

11.5.1 常见的资金安全防护策略

11.5.2 大促资金安全防护

11.6 大促经验沉淀

11.7 大促保障实战分析

11.7.1 机房网络瓶颈问题分析

11.7.2 集群个体异常造成的容量问题分析

11.7.3 诡异的网络瓶颈

11.7.4 多机房压力测试流量不均问题分析

11.7.5 Tengine限流案例

11.8 总结

第12章数据分析驱动性能优化

12.1 WebP性能优化案例背景

12.1.1 WebP格式开始兴起

12.1.2 WebP改造使L-D转化率下降

12.2 性能优化中的数据分析原理与方法

12.2.1 数据分析简介

12.2.2 数据分析之杜邦分析

12.2.3 数据分析之多维分析

12.3 通过数据分析来诊断WebP的性能问题

12.3.1 指标定义

12.3.2 基于指标树自动诊断WebP的性能问题

12.4 案例：通过数据分析进行OLAP分析和RT优化

12.4.1 在线分析系统响应指标基线的定义

12.4.2 性能问题诊断

12.4.3 数据的获取及觉察

12.4.4 方案的推导

12.4.5 小结

12.5 通过函数抽象进行性能优化

12.5.1 优化过程简介

12.5.2 函数抽象

12.5.3 统计分析

12.5.4 小结

　　11.7 大促保障实战分析
　　11.7.1 机房网络瓶颈问题分析
　　1．问题摘要
　　为了评估容量和机器数，以方便水平扩展，传统的方法有线上引流压力测试、线下脚本压力测试和线上脚本补充流量压力测试，这些方法是通过对单机的极限QPS和目标总QPS进行评估来确定需要多少机器的，单机压力测试只能发现单机的性能瓶颈，主要作用在容量评估本身。单机压力测试需要保证各个系统没有其他瓶颈，而在实际用户访问过程中，用户对整个集群进行访问，也就是说压力在整个集群上，整个集群是否存在瓶颈通过单机压力测试很难发现。集群压力测试就是为了发现整个集群的瓶颈。
　　总的来说，单机压力测试的出发点是评估单机的容量，作为机器扩容的依据，同时也能发现单机的瓶颈。集群压力测试是在单机压力测试的基础上验证是否能提供预想中的QPS服务能力（单机′机器数），当明显不能时，说明集群存在瓶颈。全链路压力测试模拟真实用户的实际流量对系统进行访问，看是否存在增加机器解决不了的问题。
　　2．全链路集群的瓶颈问题定位
　　1）木桶理论是瓶颈问题定位的理论依据
　　要想知道用户在实际访问过程中，集群是否能提供正常的服务能力，可以通过集群压力测试把系统的问题找出来。性能优化的一条很基本的原则是，所有的性能优化都符合木桶理论：一个水桶无论有多高，它盛水的高度取决于其中最短的那块木板。一个集群的服务能力有多高，取决于依赖方服务能力最弱的系统。
　　2）通过差异对比来发现集群瓶颈
　　经过数十次故障排查，并借鉴压力测试的经验，以及通过集群中服务器的差异表现对比能够发现集群的某些瓶颈。差异对比是符合木桶理论的，表现有差异的系统和机器（虚拟机）往往是某些资源瓶颈的标志，而这个出现瓶颈的资源其实就是木桶理论中最短的那块木板。差异化对比符合自然界的规律——完全对等的系统理论上是不存在的，这个不对等有人为因素，如同一应用硬件配置不同；也有客观因素，如同一应用所接收的流量不同；部署在不同的机架上，网络流量有差异，交换机网卡的配置不同，机架里面的机器不对等，造成流量不同等。
　　3）差异对比的操作步骤
　　首先查看同一个应用中RT的变化，找出RT变化大的应用。
　　其次分析RT变化大的机器，看它们的共同特性，例如网络配置、机器配置等，分析常见的资源瓶颈点。配置不同、网络流量不同、内存不同、硬盘不同、连接到后端的服务表现不同，通过分析一般都能找到瓶颈。
　　3．常见的资源瓶颈
　　同一个应用有问题的机器表现出异常大的RT，通常是网络出现瓶颈的标志，同时因为硬件配置不同，RT表现也会不同。RT和QPS是结果，而RT和QPS表现是否一样取决于资源，这些资源的表现是性能问题的原因，由结果到原因可以定位出是哪方面资源出现了问题，这样可以有针对性地排查问题，通常资源瓶颈包含以下几种。
　　1）后端服务能力不足
　　集群压力测试的压力在整个集群上，包括后端服务的压力，当服务容量不足时，RT会明显升高，当超过应用调用服务的超时时间时，应用会出现明显的超时异常。所以要确定这个问题，要看应用依赖服务的耗时是否有增加。
　　2）本机内存、CPU访问瓶颈
　　在Java构建的系统中，内存出现瓶颈，很明显GC的次数会增加，这个问题很容易发现，GC次数变多，相应QPS会很低，同时CPU的消耗也会明显变大，RT也会飙升。出现CPU瓶颈的标志是Load超过应用所在虚拟机配置的CPU核数、任务排队，同样RT也会飙升。注意，集群压力测试能够发现这种问题，单机引流压力测试同样也能够发现这种问题，所以这不是机器水平扩展的瓶颈。
　　3）物理机网卡限制
　　宿主机的网卡一般都是双网卡配置，双网卡的流量上限一般为2GB，而定位这个问题需要查看物理机的网卡监控。另外，如果开启IPtables（防火墙），需要查看net.IPv4.netfilter. IP_conntrack_max的配置，因为这个参数设置较小会导致网络丢包，进而造成TCP重传，最终导致耗时大量增加。
　　注：IP_conntrack_max是允许的最大跟踪连接条目数，Linux 2.4以下版本的查看命令为cat /proc/sys/net/IPv4/IP_conntrack_max，Linux 2.6以上版本的查看命令为cat /proc/sys/net/IPv4/ netfilter/IP_conntrack_max（old /proc/sys/net/IPv4/IP_conntrack_max is then deprecated!），查看当前的IP_conntrack_count的命令为cat /proc/sys/net/IPv4/netfilter/IP_conntrack_count。
　　4）交换机网络瓶颈
　　大型网站机房的机器部署都在机柜或者机柜所在的机框里。对于机架式服务器，1U的机柜可以放置24台物理机，每台物理机的网卡平均上限为20GB（2条线）/24 = 0.8GB。对于刀片式机柜，每个机柜包含4个机框，每个机框可以放置16台物理机，如果是千兆网卡，平均上限为2GB（两条线）/64 = 0.32GB，如果是1虚4，每台允许的流量将更小，这就是网络出问题的原因。
　　5）数据库瓶颈
　　数据库常见瓶颈有两个，第一个是连接数瓶颈，例如之前交易都依赖于Oracle数据库，无法水平扩展，Oracle连接数上限为2000，而应用都通过二方库直连数据库，应用的QPS一般偏低（和页面的渲染导致CPU消耗过大有关），所以应用的机器数量远大于服务所使用机器的数量，应用部署的发散性导致连接数瓶颈。第二个是数据库本身的QPS服务能力相对于集群压力测试的流量压力偏小，例如针对数据库能够承受的峰值QPS，数据库管理员找到方法对TOP10的SQL进行压力测试，在预设指标没有实现时，测算出数据库的峰值处理能力，数据库的容量评估通过这种方式有了数据依据，之前只能通过人工确认。
　　6）存储瓶颈
　　实际上对于应用集群压力测试本身而言，存储瓶颈比较少见，因为图片存储大部分都从CDN走了，所以CDN链路上会出现这个问题，但是集群压力测试是通过回放访问日志来实现的，而这些日志不会访问图片或者资源。这也是集群压力测试不能覆盖的一个点，希望大家关注CDN的容量，特别是源站的容量问题。
　　4．实战过程全景重现分析
　　在本案例中，对集群进行压力测试时发现集群中某些机器的RT表现有很大的不同，有些机器的RT特别大，大促技术保障目标是4万QPS，在开始集群压力测试时集群极限能够提供的QPS只能达到11000多。
　　……

　　序言
　　写书的初衷和背景
　　笔者是2011年进入阿里的，随着业务量的逐步增长，对系统的挑战越来越大，系统的容量瓶颈也越来越明显。记得刚来的时候，业务部门要做一次促销，想知道我们的系统能不能撑得住，这个问题对于没有任何经验的同学，是很难有精确答案的。后来与同事交流并结合实践，才慢慢知道了大促的技术保障过程是怎样的。
　　在笔者的经历中，有太多的故事想讲给那些需要的同行们，以避免他们犯同样的错，可以做到以史为鉴。即使是阿里内部的员工，也不是每个人都有机会接触大促、接触性能优化工作的。所以这本书的初衷就是将实践经验分享给同行们，让同行们也有所收获。
　　文字最大的魅力是提升记忆的深度，特别是美好的东西更值得记录下来，等数年或者数十年后再去回首时，也是人生中非常美好的事情。这个世界我们曾经来过，将往事沉淀，当年很多让人觉得非常有挑战的事情，如果没有文字的记录和时间的沉淀，再回首时，可能已经忘记了大半。再回首2012年以来解决的很多难题，记忆中能够留下的已经不多，这也促使笔者决定总结一下，以便帮助更多的人。
　　从2012年开始，笔者和搭档荣华、新兵开始逐步切入大促的保障工作，并同时开始负责性能领域的工作。从事和性能相关的工作十分有趣，也很容易提升知识的深度和广度。一个大型网站在构建过程中，不仅包括容量优化，还涉及体验相关的优化，而且必须能够随时回顾这些知识。本书实际上经过3年的沉淀和不断修整，在繁忙的工作之余写下这些文字，是需要毅力的。市面上很多与性能相关的书讲实践的偏少，本书最大的特点就是实践偏多，通过实践进行理论升华。书中的很多内容都是3位作者一个字一个字写下来的，这是非常不易的。
　　人生是一场修炼的过程，不断地突破自己的舒适圈，不断地和内心的懒惰做斗争，咬牙做下来，才能体会到这件事情的不易，轻易得到的总是不会太珍惜。我们处于飞速发展的时代，同时我们也处于浮躁的时代，这个时代造就了很多英雄，但也很容易在其中迷失自己。在迷失的时候，给自己定一个目标，只有不断地学习和努力，同时摆正自己的心态，明确自己想要的东西，才能处在浪潮之巅，在时代的浪潮里留下自己的痕迹。希望本书也能留下一丝痕迹。
　　关于作者
　　本书的作者是在实践中逐步成长起来的架构师，在项目的实践中，全力以赴地解决各种难题。笔者2008年认识荣华，2011年认识新兵，他们给了笔者很多支持。特别是2008年在Cisco工作的过程中，荣华给了笔者很多支持，笔者跟他学到了很多东西。当年JavaEye非常盛行的时候，荣华（以笔名ahuaxuan）在javaEye论坛里名气很大。笔者在加入Cisco之后，有幸与他成为同事，他教会了笔者很多东西。新兵负责过前端性能优化部分，他在前端性能方面有比较深入的研究，我们一起合作过多个优化的实践项目，并且在实践过程中取得了良好的效果。大家因为共同的爱好和兴趣而聚在一起，在策划这本书时，我们很快形成共识，大家因为志同道合而相聚，都知道这本书的意义。作为一个技术人，从一点点的知识学起，从不会、不了解，到慢慢深入，每个人在这个过程中的沉淀有所不同。本书只是从我们3个人的角度进行性能优化体系的阐述。
　　本书的体系是非常广的，可能只有很少数的人对每个部分都比较精通，碰巧的是我们3个人，是熟悉不同领域的工程师，这样可以各自发挥特长，让本书更有味道，也更有广度。本书是市面上第一本从前端到后端，从CDN、DNS到TCP，到机房、大促全链路的关于性能优化的书籍，能够通晓这些知识，是一个工程师或者专家很难做到的。本书主要突出全面性和实战性，是目前笔者认为的最全面的关于性能优化的书籍，本书试图打造端到端的优化理论和实战体系。
　　本书的主要结构
　　本书以大型网站性能优化实战为主题，讲述了性能优化的基本理论和实践策略。
　　第1章介绍影响用户体验的几个关键要素，重点讲解白屏、首屏及页面整体加载的过程，针对它们提出了比较系统的优化策略和常见方案。
　　第2章主要介绍前端性能优化实战，包括延迟渲染和SEO页面的优化。重点讲解了加快页面渲染速度的基本思路及具体的实践解决方案，以及SEO页面的优化思路和解决方案。
　　第3章介绍如何借助站外优秀的性能测试工具，以及建立网站自己的真实用户性能监控系统，来测试和监控页面的这些关键性能指标，从而使我们能够快速对网站性能问题进行分析并做出优化。
　　第4章讲述服务器端性能优化理论体系和实战，包括服务器端的性能优化方法和常见的优化策略。重点包括QPS的优化、同步模型与异步模型对性能的影响、数据结构对性能的影响、算法设计不合理带来的性能问题，以及一个综合案例。
　　第5章阐述TCP优化，介绍了TCP的基本原理，并对TCP近几年的发展做了介绍，最后介绍了一个项目中的TCP优化实战案例。
　　第6章讲述DNS的一些优化方案，主要从DNS的基本原理出发，结合跨境DNS部署和实战经验，介绍了DNS优化的历程。
　　第7章介绍CDN的优化实践，重点包括CDN的工作原理、CDN优化的常见策略，同时介绍了大量的优化案例，最后总结了CDN的优化原则。
　　第8章主要讲述大型网站的性能监控需求和监控指标，以及如何实现监控，揭开大型网站性能监控体系的面纱。
　　第9章主要介绍大型网站如何进行容量评估，重点包括单机峰值QPS的测算、大型网站常用的容量评估方法。
　　第10章高性能系统架构模式，主要从宏观角度来看性能优化。好的架构是高性能的基础，只有从架构上解决问题，才能将高性能有效地持续下去。好的高扩展架构比局部优化带来的效果要大得多，如同人们经常说的，格局决定高度。
　　第11章重点介绍大促的整体方案和细节工作，辅以案例，加深读者的印象。大促保障是性能优化的重要力量，由于大促保障本身是成体系的，除了性能优化，还介绍了稳定性保障和资金安全保障的内容。
　　第12章数据分析驱动性能优化，从数据视角介绍如何进行性能优化，重点包括性能优化相关的数据分析原理与方法，以及如何在实践中使用数据分析来进行大型网站的优化。
　　周涛明
　　2018年11月