性能测试---响应时间

= =
响应时间一直让我很困惑
1 响应时间是程序处理一个请求的时间
2 响应时间是用户发出请求到接到返回的时间
一些性能测试工具，类似testng  jmeter等统计的都是时间2，然后2在很大程度上受限于网络传输；而对于服务端的监控软件，响应时间的统计却太偏离与用户体验。
查看了<虫师>关于响应时间的体会后，恍然大悟，性能测试的标准：双方认可的参数定义即可
结论：给出在某网络环境下的响应时间参数
如下：为虫师大人的文档

从用户角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。 

 响应时间过程分析

　　我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分，呈现时间，数据传输时间和系统处理时间。

呈现时间

　　其实主要说的浏览器对接收到数据的一个处理展示的过程。几年前大家都在用IE，如果页面显示比较慢，我们肯定不会怪罪IE，只会怪罪电信运营商的网速或被访问的系统（其实，大多情况我们不会考虑是被访问系统的问题）。现在chrome来了，我们会发现同一台电脑同一个网站，通过chrome去访问，页面的呈现速度会比IE略快。这是各种评测及大众用户的整体感受。当然，我个人感觉，opera浏览器的呈现速度最快，但它的显示效果一直不太好。

　　当然，我说这个呈现时间总不能全怪罪与浏览器的身上吧！当然还和承载它的操作系统有关，以及电脑硬件（比如cpu 内存）。假如你有超快的浏览器，如果是一台极其垃圾的电脑，我想你多打开两个网页就有可能使电脑卡掉。

数据传输时间

　　千万不要忽视数据传输时间。如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。（ps, 我10天前在china-pub订购的一本书现在还没到货！XXX）

　　拿我们系统的数据传输过程来说，我们发送一个请求需要时间，系统处理完后返回给我们也需要时间。初学性能测试工具的同学喜欢拿工具去测试互联网上的一些系统，甚至不懂性能的同学认为可以用性能测试工具将互联网上的一些网站压崩溃。貌似这一招比任何黑客攻击厉害多去。

　　那么，我觉得这些同学应该补补网络知识了，你的带宽是多少？互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。有没有考虑网络延迟？就算你的并发请求都能成功的发出，但到目的地的时候，已经不能叫并发了。

　　这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，也有特殊的性能测试需要在互联网中时行。它们重点不是求用户的最大的并发量。

系统处理时间

系统得到请求后对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间，因为前面的呈现时间和数据传输时间都我们不可控制的，用户使用的电脑及浏览器千差万别，用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短暂。

如果我们对系统的的处理进行分析和讲解的话，它会是一个非常庞大与复杂的过程。语言、语言框架、中间件，数据库、系统架构以及服务器系统。所以，想成为一个优秀的性能测试工程师我们的路还很长。

 

实际性的能测试

     听了上面的分析，貌似每个过程都挺“浪费”时间，那么我们如何只测试系统的处理时间呢？

　　其实现在的测试工具都屏蔽呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，页不会将服务器的每个响应都向客户端呈现。

　　对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。

 

 响应时间的定义：

响应时间

　　指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。

系统响应时间

　　应用系统从发出请求开始到客户端接收到响应所消耗的时间。需要注明的是，这样的定义完全是个人喜好。你可以提异议。

  因此，在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。