[架构师训练营第 1 期] 第七周学习总结

本周对性能测试有了一个全面的了解。

性能测试概述

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

不同视角下的网站性能有不同标准，也就有不同的优化手段。

• 主观视角：用户直观感受的性能

• 客观视角：性能指标衡量的性能

两种视角并不统一。

主观视角的性能优化通常从用户体验入手。（如渲染先后顺序、即时反馈如进度条等）

客观视角的性能优化通常从技术指标入手。

性能优化的最终目的是为了提升用户体验，主观视角的性能的优化体现在表面上，客观视角的性能提升体现在本质上，后者是前者真实性和可靠性的保证。比如前端缺少后端支持，渲染了一些假数据，主观视角上性能提升了，但实际上并没有。

主观视角的产品性能主要由产品经理关注，客观视角的产品性能主要由架构师关注。

总而言之，为了提升用户体验，必须优化产品性能，为了优化产品性能，必须找到产品性能问题，为了找到产品性能问题，必须做性能测试并分析其结果，而如何展示一个可分析的性能测试结果，就必须引入性能测试指标，而如何获得性能测试结果，就必须引入性能测试方法，为了更全面地测试系统性能、保证系统在特别高并发的情况下的高可用，还必须做全链路压测，而获得测试结果后，还需要采取相应的性能优化手段。

性能测试指标

常用的性能测试指标有：

• 响应时间（核心）

• 并发数（核心）

• 吞吐量（核心）

• 性能计数器（辅助，反映资源利用率等）

响应时间

定义：应用系统从发出请求开始，到收到最后响应数据为止，之间所需要的时间。（服务端反之）

响应时间是系统最重要的性能指标，直观反映了系统的“快慢”。

并发数

定义：系统能够同时处理请求的数目。

反映系统的负载。

对于网站，并发数可以是：

• 系统并发用户数（同时提交请求的用户数目，或同时正在处理的请求数）

以下不是并发用户数：

• 在线用户数（当前登录系统的用户数，可能没有同时发送请求）

• 系统用户数（可能访问系统的总用户数，同上）

通常：系统用户数 >= 在线用户数 >= 并发用户数

吞吐量

定义：单位时间内系统处理的请求数量。

反映系统的处理能力。

对于网站，吞吐量可以用以下两个单位来衡量：

• 请求数/秒

• 页面数/秒

• 访问人数/天

• 处理业务/小时

相关指标包括：

• TPS：每秒事务数

• HPS：每秒 HTTP 请求数

• QPS：每秒查询数

吞吐量与并发数的关系：吞吐量等于响应时间为 1 秒 的并发数。

比如：系统的响应时间为 500ms，则吞吐量 = 并发数/500ms = 2×并发数/秒

吞吐量 = (1000 / 响应时间 ms) × 并发数

性能计数器

定义：描述服务器或操作系统性能的一些技术指标。

包括：

• 系统负载

• 对象与线程数

• 内存使用

• CPU 使用

• 磁盘与网络 I/O

• 等

使用时通常对这些指标设置报警阈值，并持续监控，当性能计数器超过预设阈值时，向运维或开发人员报告异常，尽快降低系统故障影响面。

性能测试方法

性能测试是一个总称，具体可细分为：

• 性能测试

• 负载测试

• 压力测试

• 稳定性测试

• 等

性能测试

定义：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能够达到性能预期。

负载测试

定义：对系统不断施加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值。

如：某种资源已经呈现饱和状态，此时持续对系统施加压力，系统处理性能不但不能提高，反而下降。

压力测试

定义：超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。

稳定性测试

定义：被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，是系统运行一段较长时间，以此检测系统是否稳定。

在生产环境下，请求压力是不均匀的，呈波浪特性。

因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。

性能测试曲线

TPS
|  |    |   |
|  | c|_|d
| b|/   |   |\
| /|    |   | \
|/|_||____系统资源（如服务器集群中服务器的数量，并发用户数等）
   5    7   10
 性  负   压
 能  载   力
 测  测   测
 试  试   试

问：若性能测试得到曲线如上，则正常生产环境应让系统大部分时间处于 a b c 哪个点？

答：放哪里都有道理，需要在成本与风险之间就实际情况做权衡。

全链路压测

性能测试的测试对象是单个接口，全链路压测的测试对象是整个系统。

一般情况下，系统测试只需要对几个关键的接口进行性能测试即可。

但在特殊情况下，如并发量特别大时，就需要考虑到一些不常用的接口，使用全链路压测来保证系统的稳定和可用。

全链路压测就是在特定的业务场景下，将相关的链路完整地串联起来同时施压，尽可能模拟出真实的用户行为。

当系统整站流量都被打上来时，必定会暴露出性能瓶颈，此时才能够探测出系统整体的真实处理能力，

并据此有指导地在实际投入运行（如大促）前进行容量规划和性能优化，这也是线上实施全链路压测的目的。

全链路压测的难点或挑战：

• 压测范围无死角

• 压测数据怎构造

• 线上压测无影响

• 压测流量怎模拟

性能优化：系统性能优化的分层思想

软件性能优化的两个基本原则：

• 不能优化一个没有测试的软件：进行性能测试才能发现性能问题，分析性能问题才能进行有目的地优化，优化之后还需要进行性能测试验证优化结果。

• 不能优化一个没有了解的软件：

性能测试的主要指标：

• 见前

性能优化的一般方法：

• 性能测试：获得性能指标

• 指标分析：发现性能与资源瓶颈

• 架构与代码分析：寻找性能和资源瓶颈的关键所在

• 架构与代码即其他优化：优化关键技术点，平衡资源利用

• 性能测试：进入性能优化闭环

性能优化的思想：分层

• 机房与骨干网络的性能优化

• 服务器与硬件的性能优化

• 操作系统的性能优化

• 虚拟机的性能优化

• 基础组件的性能优化

• 软件架构的性能优化

• 软件代码的性能优化

机房与骨干网络的性能优化

• 异地多活的多机房架构

• 专线网络与自主 CDN 建设

服务器与硬件的性能优化

硬件性能优化案例：Spark 1G 网卡 -> 10G 网卡

操作系统的性能优化

硬件性能优化案例：Spark 部分版本 Linux Transparent huge page 选项默认开启 -> 关闭

虚拟机的性能优化

虚拟机的性能优化案例：Java 虚拟机

基础组件的性能优化

基础组件的性能优化案例：ODBC 中间件 Jetty 7.5.2 替代 JBoss4.0.5GA

软件架构的性能优化

软件架构的性能优化案例：

• 缓存：优化读性能

- 从内存中获取数据：降低响应时间

- 减少数据库访问：降低存储设备负载压力

- 缓存结果对象而非原始数据：降低 CPU 计算量

• 异步：优化写性能

- 即时响应：降低响应时间

- 控制消费速度：产生合适的负载压力（削峰填谷）

• 集群：

软件代码的性能优化

遵循面向对象的设计原则与设计模式编程。

很多时候不是性能上有什么技术挑战，而仅仅是代码写得太糟糕。

先写好代码，再关注技术方面，如：

• 并发编程：多线程与锁

• 资源复用：线程池与对象池

• 异步编程：生产者与消费者

• 数据结构：数组、链表、hash 表、树等

软件代码的性能优化案例：Spark