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

大型网站性能优化实战 从前端 网络 CDN到后端 大促的全链路性能优化详解 作者：周涛明，张荣华，张新兵

大型网站性能优化实战 从前端 网络 CDN到后端 大促的全链路性能优化详解 出版社：电子工业出版社

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

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

《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》的初衷就是将实践经验分享给读者，展示性能优化相关知识的全貌。《大型网站性能优化实战：从前端、网络、CDN到后端、大促的全链路性能优化详解》中的很多性能优化方法和策略都是作者从实践中总结出来的，实用性非常强。《大型网站性能优化实战：从前端、网络、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 小结

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

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多。