Java性能权威指南读书笔记二性能测试方法

前言

本章讨论了性能测试的4个原则，这些原则是后续章节的基础，也涵盖了性能工程科学的各个方面。

原则1：测试真实应用

第1条原则就是，应该在产品实际使用的环境中进行性能测试。性能测试的方法大体分为三种，每种都有其优点和不足，只有适用于实际应用的才能取得最好的效果。

1 微基准测试

第一种是微基准测试。微基准测试用来测量微小代码单元的性能，包括调用同步方法的用时与非同步方法的用时比较，创建线程的代价与使用线程池的代价。

1.1 必须使用被测的结果

如果被测试代码的结果没有被使用，那么编译器可以很放心地去除计算结果。解决的方法是将局部变量结果改为实例变量（并用关键字volatile声明）。

1.2 不要包括无关的操作

除了想要被测试的代码，不要包含其他的代码

1.3 必须输入合理的参数

用大量不常见的参数作为输入，那么性能测试的结果就不具有实际的意义。

2. 宏基准测试

宏基准测试就是整体测试，不进行整体测试，就不知道系统在实际的业务中到底会具有怎样的性能。

3. 介基准测试

类似模块测试，介于宏基准测试和微基准测试之间。是一种合理的折中途径，有必要的存在性。

原则2：理解批处理流逝时间、吞吐量和响应时间

1 批处理流逝时间

在非Java的世界中，可以直接地测试流逝时间：应用记下时间点从而测量执行时间。但在Java的世界中，由于JIT，会有问题。
因此，研究Java的性能优化要密切注意代码优化的热神期：大多数情况下应该在运行足够长时间后，已经编译优化后再测量。
另一方面，从应用开始启动到结束的这段时间也是同样重要的。

2 吞吐量测试

吞吐量测试是基于一段时间所能完成的工作量。这个指标通常被叫做每秒事务数（TPS），每秒请求数（RPS），每秒查询数（QPS）

3 响应时间测试

响应时间是从客户端发送请求至收到响应之间的流逝时间。
衡量响应时间的方法：

平均值法：请求时间到总和除以请求数。
百分位请求法：例如90百分位响应时间。如果90%的请求时间响应小于1.5秒，且10%的请求时间大于等于1.5秒，则1.5秒就是第90百分位响应时间。
ps：平均值会受离群值影响（突然出现一个非常大的值对平均值影响很大）

原则3: 用统计方法应对性能的变化

即使是相同的测试集，也会产生不同的性能测试结果。因为会有很多因素影响到程序的性能，例如：机器上的后台进程，网络情况等等。
一种方法是多次测试比较平均值，然而这也并不能解决问题。所以

原则4：尽早频繁的测试

我理解对于性能测试应该伴随着开发的过程，如果中间有性能的衰减，应该停止提交代码，然后在性能正常后再继续开发。
以下几条原则可以提高测试性能：

自动化一切

所有的性能测试应该自动化
全部环境必须通过脚本安装和配置新代码（创建数据库连接，建立用户账户等），然后用脚本运行测试集。
脚本必须能够多次运行测试，对结果进行t校验分析，并能生成置信度报告。说明统计结果是相同还是不同，不同的话相差多少。
在测试前，通过自动化技术确保机器处于稳定状态。检查是否有不希望运行的进程，操作系统配置是否正确。
ps：只有环境系统，性能测试才是可重复的。

测试一切

收集每一点数据，以便进行后续分析。

运行过程中系统信息：CPU使用率，磁盘使用率，网络使用率，内存使用率等。
应用的日志
垃圾收集器的日志
还可以有对系统影响比较小的profiling信息或者jfr信息。
周期性线程堆栈信息，以及其他堆信息
相关系统的信息：数据库

在真实的系统上运行

如果条件允许，最好和正式运行的相同的机器上运行。
很多jvm的参数是根据硬件的条件计算出来的。另外平台和平台之间编译出来的代码也不相同。这些都会造成性能测试的结果不同。

总结

性能测试是一门艺术，同时建立在科学理论的基础上。