性能测试是一项不可避免的任务，但问题是怎么保证测试的指标是正确且合理的？在这篇文章中，你将会了解到为什么常见的主要测试指标是不完美的，以及十个新的测量指标 —— 它们可能会改进你未来的性能测试报告。
在很多企业中，性能测试是定期进行的。作为这些测试的一部分，质量保证团队会收集各种指标并将其发布在性能测试报告中。性能测试报告中常用的一些分析指标是 CPU 利用率、内存利用率，关键事务或后端系统的响应时间以及网络带宽，具体取决于企业自身的情况。
我更愿意将这类指标归类为宏观指标，宏观指标当然很好，但它们有两个不可忽视的主要缺点：
-
不能在测试环境中捕获到性能问题
尽管在测试环境中进行了许多性能测试，但在生产环境中仍然会出现性能下降的情况。在测试环境中，你也许会注意到性能急剧下降的情况，但上面提到的宏指标并不能帮助你发现问题的根源。这些急剧的下降在生产环境中的体现就是主要的性能问题。下面讨论的微观指标会为这些下降的情况带来可见性。
-
宏观指标对解决问题没有帮助
在很大程度上，宏观指标不能帮助开发团队调试和排除故障。例如，如果宏观指标显示 CPU 消耗高，它不能表明这是由于垃圾收集活动、线程循环问题或其他编码问题而导致的 CPU 消耗增加。同样的，如果响应时间下降，也不会有任何指标显示是由于应用程序代码中的锁定还是后端连接问题而导致的下降。
因此，我的观点是应将宏观指标与微观指标一起搭配使用。在这篇文章中，将列出十项我认为最重要的微观指标，你可以考虑将其中的一些或全部添加到你的性能测试报告中。
与内存相关的微观指标
1. 垃圾回收机制的暂停时间
我们应该测量垃圾回收的暂停时间，因为应用程序会在 GC 暂停期间处于被挂起的状态。这意味着这段时间里不会执行 customer activity，很显然这是不好的。降低 GC 暂停时间的数量和长度可直接影响到性能。所以我们应始终力求实现最短的暂停时间。
2. 对象的创建/回收率
创建对象的速度会严重影响 CPU 的利用率。如果使用低效的数据结构或代码，会生成更多的对象来处理相同数量的事务。过高的对象创建率会导致出现频繁的垃圾回收行为，而频繁的 GC 则会增加 CPU 的消耗。
3. 垃圾回收的吞吐量
简单来说，吞吐量是指应用程序线程用时占程序总用时的比例。 例如，吞吐量 99/100 意味着 100 秒的程序执行时间应用程序线程运行了 99 秒， 而在这一时间段内 GC 线程只运行了 1 秒。我们应力求实现高吞吐量，即应用程序应运行更多的时间，并减少垃圾回收活动的时间。
4. 每一次生命周期的内存消耗
在 JVM、android Runtime 和其他的平台中，内存会被划分为几个内部区域。我们需要知道分配的大小空间以及每个区域的峰值利用率大小。内存区域的分配不足会降低应用程序的性能，而超额的分配将增加托管服务器的成本。
如何获得与内存相关的微观指标？
所有这些与内存相关的微观指标都可以从垃圾回收日志中捕获。
与线程相关的微观指标
5. 线程的状态
线程会处于以下的其中一种状态：新建，可运行，运行中，睡眠，阻塞，等待，死亡。性能测试报告中应体现出每个状态的线程数量。如果线程长时间处于阻塞状态，则应用程序可能会无法响应。如果许多线程处于可运行状态，那么应用程序的 CPU 消耗就会变高。如果应用程序的线程在等待、有时间限制的等待和阻塞状态中花费更多的时间，这将会降低响应时间。
6. 线程组
线程组表示一组线程的集合。每个应用程序都会被归属于多个线程组。我们应该测量每个线程组的大小并记录在性能测试报告中。线程组大小的增加可能表示着某种类型的性能下降。
7. 守护进程 vs 非守护进程
有两种类型的线程状态：守护进程和非守护进程（如用户线程）。我们应该按状态来对线程进行报告。因为当非守护线程在运行时，JVM 将不会终止。
8. 代码执行路径
应用程序的 CPU、内存消耗和响应时间会根据代码执行路径而有所不同。如果大多数线程执行特定的代码执行路径，我们应该详细研究该特定的代码执行，以防止出现瓶颈或效率低下的情况。
如何获得与线程相关的微观指标？
线程相关的指标可从线程线程转储中获得。
与网络相关的微观指标
9. 出站链接
在当今世界，很少会看到不与其他应用程序通信的企业应用程序。你的应用程序的性能在很大程度上取决于与它所通信的应用程序。我们应测量每个端点的 ESTABLISHED 连接数量。连接数量的任何变化都会影响应用程序的性能。
10. 入站链接
应用程序可从多个渠道获得流量：Web, Mobile, API 和多种协议：HTTP, HTTPS, JMS, Kafka 等等。你需要测量来自每个通道和每个协议的连接数，因为它们也会对应用程序的性能有很大的影响。
如何获得与网络相关的微观指标？
应用程序性能监视(APM)工具可以报告此指标，也可以在 APM 工具中配置自定义探针来获取这些指标的数据。此外，如果不使用 APM 工具，也可以使用 ‘netstat’ 工具。
netstat -an | grep ‘hostname‘ | grep ‘ESTABLISHED‘
这里推荐三个开源的 APM 工具：
-
SkyWalking — 针对分布式系统的 APM 系统，也被称为分布式追踪系统，对 Java 分布式应用程序集群的业务运行情况进行追踪、告警和分析。
-
Zipkin — 推特开源的分布式跟踪系统，参考了 Dapper 体系。
-
Pinpoint — 用 Java 编写的 APM 工具，用于大规模分布式系统。在 Dapper 之后，Pinpoint 提供了一个解决方案，通过 JavaAgent 的机制来做字节码代码植入，实现加入 traceid 和抓取性能数据的目的，以帮助分析系统的总体结构以及分布式应用程序的组件之间是如何进行数据互联的。