性能测试——1、几个关键性能指标梳理

性能需求分析、性能结果分析都离不开并发用户数、响应时间、吞吐率这几个指标。平时工作中客户、项目经理最关注的是响应时间，而这个指标必须与吞吐率和用户数组合一起说才会有意义。

    1、并发用户数：在同一个时刻做同一操作的所有用户数。应该与系统用户数、同时在线用户数做些区别。系统用户数是指可使用系统的用户数量，如注册的用户数。同时在线用户数是指同时登录系统的用户数量。比如一个web系统，有2W注册用户，根据调查发现通常有5K用户是活跃用户，有800用户会同时执行发帖操作。则系统用户数是2W，同时在线用户数是5K，对某一操作而言并发用户数是800。在做性能测试需求分析时，需向客户、需求人员或项目经理调研这部分数据。

    2、响应时间：对于某事务，客户发出请求到得到回应的整个过程的时间，也就是从第一个请求开始到客户端收到最后一个字节的响应所消耗的时间。一般关注的是服务端系统处理的时间，2s、5s、8s是普遍对响应时间优劣的认知。
   一个事务处理过程主要包含四段时间，request传输时间、系统处理时间、response传输时间、呈现时间。对于loadrunner而言，response time只反映了传输时间和系统处理事务的时间，而客户的浏览器从接收完所有字节开始到浏览器加载完所有元素、运行完所有js，呈现给用户的这段时间loadrunner是不统计的，这部分属于页面前端性能，可使用firebug、httpwatch、page speed、yslow、fiddler、charles等工具进行测试。
我用过firebug，在做前端性能监测时，主要关注的是timeline面板。
 1)阻挡(Blocking)：每个浏览器有并发连接数量的上限（例如Firefox对每个host限制6个连接），如果当前建立的连接数已经超过上限，那么其余该请求会被阻塞，等待新的可以用的连接。

2)域名解析(DNS Lookup)：这个不用解释了吧，就是从DNS请求发出去到收到回复的时间。即上图中DNS的那一段。

  3)建立连接(Connecting)：三次握手建立TCP链接的时间。如果是HTTPS的话，还有SSL链接的时间。对应图中TCP那一段。

  4)发送请求(Sending)：从发送本次请求的第一个bit，到最后一个bit。对应图中Request

  5)等待响应(Waiting)：从发送结束起，到收到host返回的第一个bit。这一段途中没有表示出来，应该是Request和Response中间的间隙。这段时间即系统处理时间。

  6)接收数据(Receiving)：从收到host返回的第一个bit，收到到最后一个bit。对应图中Response

另外在timeline右下角还有两个时间：

1）DOMContentLoaded：事件，DOMContentLoaded事件完成的时间，从请求发起时开始，到所有页面元素加载完成。

3、吞吐率：单位时间内网络上传输的数据量。在loadrunner中有三个常用的指标可表示吞吐率。

1）TPS(Transaction per second，事务数/秒)：每秒系统能处理事务或交易的数量。事务是用户某一步或几步操作的集合，如一次登录，一次淘宝订单支付过程，一个事务中可能会包括n个request和response的过程。经验值是10个事务数/秒~100个事务数/秒。

2）HPS(Hit per second，点击数/秒)：每秒用户对web页面链接、提交按钮等点击的数量，一般与TPS成正比。

3)Throughput/s:每秒系统处理的客户请求的数量（bytes）。由于throughput只是服务器返回的字节数，因此吞吐率可理解为单位时间内客户收到的服务器返回的字节数。

提供一个真实项目的性能数据作参考：

并发用户数      throughput/s    TPS       HPS    average response time(某事务)

60              47万           17.32     341      3.9s

100             61.6万         26.45     560      4.2s

由以上数据可知，1）就吞吐率而言，单位时间内，相同的事务，如果系统能承载压力的情况下，Vuser越多，则吞吐率越大；2）系统的性能测试应事先确定测试目的，如果想知道一个系统各项指标的极限值，则应循序渐进，逐渐加压，如缩短时间、增加虚拟用户数，当各个指标达到顶峰后开始呈下降趋势时，那个顶峰值才是系统的最优性能数据；3）评判一个系统的性能时，需结合用户数、单位时间、业务量、吞吐率等来进行统一描述，单独谈一个指标没什么意义。