1. 性能测试

性能优化的前提，是性能测试，没有测试就不知道当前系统的性能是怎么样子的，优化完了以后也不知道具体提升了多少，不知道是变好了还是变差了。前面几章讲了一些性能优化的方案和工具，并不是用了就解决问题了，而是要经过性能测试，知道当前系统的瓶颈所在，针对性的进行优化，在考虑要使用什么方案和工具。

提升了多少要有一个量化的标准，性能测试就能得到具体的数字，可以看到的结果，而不是感觉系统很快或者很慢。



性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的性能有不同标准，也有不同的优化手段。



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

用户感受的性能是主观上的感受，比如用户打开网页的时候有2种展示方式，一种是等所有资源下载完毕在展示给用户看，另一种是一边加载一边展示。时间上都是一样的，但是效果上却是不一样的。加载网页总时间需要3秒钟，全部要加载完毕再展示的方式会有3秒钟的空白期，用户就会感觉这个网站性能不好，这么慢。要是一边加载一边展示，用户很快就能看到，并且感觉到了网站在和他交互，就会感觉很快，性能很好。实际上响应时间是一样的，都是3秒钟。



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

2. 性能测试指标

不同视角下有不同的西能你标准，不同的标准有不同的性能测试指标，网站性能测试的主要指标有响应时间，并发数，吞吐量，性能计数器等。



• 响应时间

指应用发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观反映了系统的“快慢”。从发出的第一个字节开始到收到应答的最后一个字节结束所需要的时间。



• 并发数

系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于网站而言，并发数即系统并发用户数，指同时提交的请求用户数目，与此对应的还有在线用户数（当前登录系统的用户数）和系统用户数（可能访问系统的总用户数）。

并发数是指同时提交了的请求，同时在服务器中处理，只要还没有应答的最后一个字节返回，这个请求都算在并发数里面了。

如果用户只是打开了app或网页，并没有发请求，这个时候是不会对系统产生压力的。



• 吞吐量

单位时间内系统处理的请求数量，体现系统的处理能力。对于网站，可以用“请求数/秒”或“页面数/秒”，也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。

TPS（每秒事务数）也是吞吐量的一个指标，此外还有HPS（每秒HTTP请求数），QPS（每秒查询数）等。

TPS指的是泛事务，并不是数据库的事务。HTTP请求和查询也算是事务。



• 响应时间，并发数，吞吐量之间的关系

当知道了其中两个的具体数值时，就能得出第三个数值了。

响应时间越短，并发数越高，吞吐量就越高。

吞吐量=（1000/响应时间ms）* 并发数



• 性能计数器

描述服务器或操作系统性能的一些数据指标。包括System Load，对象和线程数，内存使用，cpu使用，磁盘和网络I/O等指标。这些指标也是系统监控的重要参数，对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值的时候，就像运维人员和开发人员报警，及时发现处理系统异常。

这些指标反映当前的系统状况。

我们希望吞吐量越大越好，并发增加的时候会消耗系统的资源，资源消耗到极限的时候，响应时间就会不断的上涨。根本就不能处理了，吞吐量就是零了。系统可能就崩溃了。



3. 性能测试方法

性能测试是一个总称，具体可细分为性能测试，负载测试，压力测试，和稳定性测试。

通过并发访问的请求，给系统性能压力然后观察各种性能指标。



• 性能测试

以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统的资源可接受范围内，是否达到性能预期。注：不断的施加压力，不断增加并发数，请求数。



如：100并发请求的情况下，响应时间为小于500毫秒。可以压一下，压到500并发的时候是否还是符合预期。



• 负载测试

对系统不断地增加并发请求以增加系统压力，知道系统的某项或多项性能指标达到安全临界值（cpu100%跑满，System Load超过了cpu核数，网卡到达了最大值）。如果某种资源已经呈现包和状态，这时候继续施加压力，系统的处理能力不但不能提高，反而会下降。



• 压力测试

超过负载的情况下，继续对系统施加压力（提升并发数），知道系统崩溃或不能在处理任何请求，以此获得系统最大压力承受能力。



• 3种测试的关系

这3种测试其实是连续的，先看正常响应的情况下，系统的资源在正常的访问范围之内是不是都能达到目标。 然后继续施加压力到达瓶颈点，然后继续施加压力系统就会进入崩溃状态。



需要把瓶颈点和崩溃点给测出来。



• 稳定性测试

被测试系统在特定硬件，软件，网络环境下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。在生产环境，请求压力是不均匀的，呈现波浪特性，因此为了更好地模拟生产环境，稳定性测试也应该不均匀地对系统施加压力。



比如系统缓存，请求压力不均匀的时候效果是不一样的，因为缓存是有失效时间的，压力大的时候正好有很多缓存数据失效，那么这个时候系统压力就会大上很多。所以需要模拟不均匀的压力。



• TPS和并发数的关系





3个阶段曲线图，纵轴是每秒事务数（请求数），横轴是并发数。刚开始并发数是0，TPS也是0， 随着并发数增加，TPS也在增加。



过了b点后，就进入负载测试了，tps增加很小。过了c点就是压力测试了，处理能力下降，最终系统崩溃。并发请求多，系统资源消耗严重，来不及处理请求了，tps就下降了。



当TPS到了b点以后，就要小心了，一不小心就有可能因为并发量继续增加而到了c点，导致系统异常。

要是想省钱，少用一点机器，TPS控制在b点的右边，但是有风险，离c点更近。

要是不省钱，多用一些机器，TPS控制在b点的左边，更安全。



安全性和成本问题，公司有钱，比较注重系统的稳定性那就把TPS控制在b点左边。如银行的系统，应该选择在b点的左边，更安全，请求并发增大，系统仍然可以稳定运行，不然要是系统崩溃了影响就很大了。



具体怎么选择不是关键，关键是知道了选择的依据是什么，才有选择的空间和余地。知道了这些东西在做决策的时候才有依据，有选择的能力。而不是脑袋里面一团浆糊，拍着脑袋做决定。



• 响应时间和并发用户数的关系



刚开始的时候并发数少，系统资源都还是空闲的，响应时间也就比较低，基本不变。当超过b点的时候，并发数多，系统压力逐渐加大，响应时间就慢慢变长。到了c点的时候系统到了最大负载，再增加就导致资源不够，请求都在排队等待处理，这个时候响应时间就在急剧增加。直到到达d点，系统崩溃。



• 性能测试例子



这个可以作为性能测试的结果展示出来。



系统优化的时候，使用什么技术或工具，并不能证明系统变好了，技术只是一种手段，并不是答案。必须要经过测试对比才能知道。



4. 性能优化

性能优化的前提是性能测试，性能优化的结果也是性能测试。优化之前测试是要找到系统的瓶颈点，找到需要优化的地方，做到有的放矢。优化之后的性能测试是为了检测优化的结果是否符合预期。是否有效果。



4.1 西能优化的2个基本原则



4.1.1 你不能优化一个没有测试的软件

没有性能测试就没有性能优化，不要一上来就进行优化，连系统的问题在哪里都不知道。并不是因为有更牛逼的技术，并不是因为现在的技术或架构弱爆了。即使是对的，也不要这样做。性能差不差是性能指标说了算，是测试的结果说了算。

4.1.2 你不能优化一个你不了解的软件

要对一个软件进行优化之前一定要了解这个关键，架构是什么样子的，核心是什么样子的。



5. 性能测试的主要指标

• 响应时间：完成一次任务（请求）花费的时间。

• 并发数：同时处理的任务数

• 吞吐量：单位时间完成的任务数（请求数）

• 性能计数器：System Load, 线程数，进程数，CPU，内存，磁盘，网络使用率。资源消耗情况



6. 性能优化的一般方法

• 性能测，获得性能指标。

• 指标分析，发现性能与资源瓶颈点。

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

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

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



7. 性能优化分层思想

从整体部署角度看系统性能分层。

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

• 异地多活的多机房架构，专线网络与自主CDN建设

• 就近为用户提供服务



• 服务器与硬件的性能优化。（垂直伸缩）

• 更好的服务器

• 使用更快的硬盘。机械硬盘和ssd硬盘差距还是很大的。

• 带宽更大的网卡

在成本可以接受的情况下，可以优先考虑更好硬件来提升系统处理能力。



• 操作系统性能优化

• 观察CPU使用情况，用户态和内核态时间，或者是操作系统使用掉的，看cpu主要消耗在哪。

• 虚拟机性能优化（java虚拟机）

• 垃圾回收的时候整个虚拟机都停顿了。

• 基础组件性能优化，防止基础组件本身有问题，影响系统。

• 通过更换组件或升级组件的版本也有助于提升性能，更高版本的组件性能可能会更好，不过也可能有bug

• 软件架构性能优化

• 参看第8节，架构性能优化三板斧

• 软件代码性能优化

• 一般情况下说到优化，第一反应就是优化代码，但是实际上。

• 遵循面向对象的设计原则与设计模式编程，很多时候程序性能不好不是因为性能上有什么技术挑战，仅仅就是因为代码太烂了。

• 并发编程，多线程与锁

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

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

• 数据结构，数组，链表，hash表，树



8. 软件架构性能优化三板斧

• 缓存

• 异步

• 集群

8.1 缓存

从内存中获取数据，而不是从数据库中获取，减少响应时间，减少数据库访问压力，降低存储设备负载压力。缓存结果对象，而不是原始数据，减少cpu计算，缓存主要是优化读操作，没有读的场景缓存是用不上的，有热点数据频繁读取的场景正是缓存最适用的地方。



8.2 异步

减少阻塞等待时间。即时响应，更好的用户体验，用户提交请求后可以即时的给用户反馈一个操作成功的提示，而不是所有操作做完后在提示，这样有可能需要等很久（也要看场景）。使用队列，可以控制消费速度，合适的负载压力。异步主要优化写操作。



8.3 集群

古老谚语：如果一匹马拉不动马车，无需换一匹更强的马，而是用两匹马拉车。

互联网技术的发展路径就是：更多的用户访问需要消耗更多的计算资源，单一服务器计算资源的增加是有极限的，所以需要增加更多的服务器。关键是如何利用起来这些服务器。

集群的技术目标只有一个：如何使多台服务器对使用者看起来像一台服务器。