性能测试(2) - 定义性能测试的指标

做性能测试前，除了需要了解性能测试的需求，我们还要定义清楚性能测试的指标。

我们所关注的性能指标

响应时间：比较熟悉的就是2-5-8原则（据统计当网站慢一秒就会流失十分之一的客户），通常来说，2到5秒，页面体验会比较好，5到8秒还可以接受，8秒以上基本就很难接受了。但是有的项目也会例外，比如从海量的数据中去查询某些数据，或者生成报告（年度报告），这种可能就不太适合2-5-8原则。但是前提是要管理好客户的期望。

吞吐量：指的是在单位时间内客户端和服务器成功传送数据的数量。

并发：客户/服务端同一批用户同时执行一个操作的数量。

资源使用率：通常来说，我们关注的资源就是几大块：内存，CPU，I/O和网络

成功率：比如在某些情况下，API调用的成功率。

怎样去定义性能指标

当了解了我们所需要关注的性能指标，就可以来定义具体的性能测试指标了。

我之前做一个比较大的项目的性能测试，系统提供很多服务，有web service，有windows的services，基本上每个services都是单独部署在一台window的服务器上，所有的services都连到同一个数据库。

由于这个系统并不存在网页，所以我们并没有把页面加载这些考虑在内。我们从历史数据中首先了解到了系统需要满足的并发量，针对每个service去做相应的压力测试，并且定义对应的性能测试指标。

下面就是对于web service性能测试的指标和结果,这个结果是我们基于每秒有7个Post请求+3个get请求而产生的。这其中的性能指标包含了我们对这个service的单独的内存监控，cpu监控，以及成功率的监控。，还有相应的原因分析。 通常来说，对于内存，CPU等的占用率，业界都有很common的标准，大家可以拿来作为参考，由于我们服务器是8g内存，8核cpu，所以表现还是相当不错的。

其他的service也是类似的，我们考察的点主要在与CPU，内存的占用率，还有成功率。由于网络一开始我们就认为不是瓶颈（都在内网），所以我们并没有把网络相应的指标加进去。 需要特别注意的数据库server，和其他windows service或者web service不一样，对于DB server我们需要特别关注的是I/O，数据库的瓶颈一般都是出现在I/O上面。

自定义指标

有了这些指标，就足够了嘛？在项目中我们往往还要自定义一些其他的指标。为了分析方便，我们在一些service的关键方法上都加上时间戳，便于去做trouble shooting。

于是我们有了一下的指标，图一是某个方法的平均调用时间，图二是我们计算出的最慢调用方法的top10：

总体来说，性能测试的指标可以从不同的方面去定义，比如响应时间，资源利用，并发数，吞吐量，并发数... 在性能测试中，这些指标往往又是相互关联的，当遇到问题时，我们需要从这些指标的结果中去寻找真正的root cause，这也是性能测试最重要的点之一，稍后我会详细介绍如何去做trouble shooting。