性能测试是一项不可避免的任务,但问题是怎么保证测试的指标是正确且合理的?在这篇文章中,你将会了解到为什么常见的主要测试指标是不完美的,以及十个新的测量指标 —— 它们可能会改进你未来的性能测试报告。
在很多企业中,性能测试是定期进行的。作为这些测试的一部分,质量保证团队会收集各种指标并将其发布在性能测试报告中。性能测试报告中常用的一些分析指标是 CPU 利用率、内存利用率,关键事务或后端系统的响应时间以及网络带宽,具体取决于企业自身的情况。
我更愿意将这类指标归类为宏观指标,宏观指标当然很好,但它们有两个不可忽视的主要缺点:
因此,我的观点是应将宏观指标与微观指标一起搭配使用。在这篇文章中,将列出十项我认为最重要的微观指标,你可以考虑将其中的一些或全部添加到你的性能测试报告中。
我们应该测量垃圾回收的暂停时间,因为应用程序会在 GC 暂停期间处于被挂起的状态。这意味着这段时间里不会执行 customer activity,很显然这是不好的。降低 GC 暂停时间的数量和长度可直接影响到性能。所以我们应始终力求实现最短的暂停时间。
创建对象的速度会严重影响 CPU 的利用率。如果使用低效的数据结构或代码,会生成更多的对象来处理相同数量的事务。过高的对象创建率会导致出现频繁的垃圾回收行为,而频繁的 GC 则会增加 CPU 的消耗。
简单来说,吞吐量是指应用程序线程用时占程序总用时的比例。 例如,吞吐量 99/100 意味着 100 秒的程序执行时间应用程序线程运行了 99 秒, 而在这一时间段内 GC 线程只运行了 1 秒。我们应力求实现高吞吐量,即应用程序应运行更多的时间,并减少垃圾回收活动的时间。
在 JVM、Android Runtime 和其他的平台中,内存会被划分为几个内部区域。我们需要知道分配的大小空间以及每个区域的峰值利用率大小。内存区域的分配不足会降低应用程序的性能,而超额的分配将增加托管服务器的成本。
所有这些与内存相关的微观指标都可以从垃圾回收日志中捕获。
线程会处于以下的其中一种状态:新建,可运行,运行中,睡眠,阻塞,等待,死亡。性能测试报告中应体现出每个状态的线程数量。如果线程长时间处于阻塞状态,则应用程序可能会无法响应。如果许多线程处于可运行状态,那么应用程序的 CPU 消耗就会变高。如果应用程序的线程在等待、有时间限制的等待和阻塞状态中花费更多的时间,这将会降低响应时间。
线程组表示一组线程的集合。每个应用程序都会被归属于多个线程组。我们应该测量每个线程组的大小并记录在性能测试报告中。线程组大小的增加可能表示着某种类型的性能下降。
有两种类型的线程状态:守护进程和非守护进程(如用户线程)。我们应该按状态来对线程进行报告。因为当非守护线程在运行时,JVM 将不会终止。
应用程序的 CPU、内存消耗和响应时间会根据代码执行路径而有所不同。如果大多数线程执行特定的代码执行路径,我们应该详细研究该特定的代码执行,以防止出现瓶颈或效率低下的情况。
线程相关的指标可从线程线程转储中获得。
在当今世界,很少会看到不与其他应用程序通信的企业应用程序。你的应用程序的性能在很大程度上取决于与它所通信的应用程序。我们应测量每个端点的 ESTABLISHED 连接数量。连接数量的任何变化都会影响应用程序的性能。
应用程序可从多个渠道获得流量:Web, Mobile, API 和多种协议:HTTP, HTTPS, JMS, Kafka 等等。你需要测量来自每个通道和每个协议的连接数,因为它们也会对应用程序的性能有很大的影响。
应用程序性能监视(APM)工具可以报告此指标,也可以在 APM 工具中配置自定义探针来获取这些指标的数据。此外,如果不使用 APM 工具,也可以使用 ‘netstat’ 工具。
netstat -an | grep 'hostname' | grep 'ESTABLISHED'
这里推荐三个开源的 APM 工具:
原文转自:https://my.oschina.net/editorial-story/blog/1576920