简介
网络对整体
响应时间的影响是是通过不同机制完成的。所选择的协议(例如帧中继或ATM，EIGRP或OSPF)会很大程度地影响数据在网络中传输的延迟时间。这些时间包括处理的时延(主机接收到数据包并获得各种信息), 排队时延(当出现了其它的信息包时)，传送或连续传输时延(传输帧中的第一位和最后一位的时间), 传输时延(一个数据位通过链路的时间，他取决于物理的介质和距离)。包的损坏和丢失也会降低信息的质量或增加额外的时延，因为需要重新传输。地面传输的企业网络，等待和传输时延是网络时延的主要问题。对于卫星网络，传输时延(加上访问协议)是主要问题。服务器时延的影响有服务器本身和应用设计两个方面。服务器本身的性能包括处理器的速度，
存储器和I/O性能，硬盘驱动速度以及其它设置。应用设计包括结构和算法。
结构
应用时延受几个独立的因素影响，例如应用设计(例如通话的稳定性)，交易的大小，选择的协议(例如
UDP或TCP)，以及网络的结构。完成一个确定的交易时，一个应用所需要的往返次数越少，它受到网络结构的影响也越小。然而，由于需要重新传输，所以往返的次数本身可能取决于网络结构。
用户的经验
计算机的用户最讨厌等待。在大量的处理环境中，超过3秒以上的响应时间将会严重影响工作效率。然而最终用户的感受不仅仅是绝对时间问题，他们对于响应时间的期望是参照以往的经验，而这种期望是相对于他们使用该应用的基准性能。如果使用该应用的当前感受和以往的经验有很大的差别时，抱怨以及需要支持的电话就会成倍地增加。
重要性
应用响应时间的问题随着基于服务器应用的大量增加而迅速增多。确定造成应用延迟的原因成为很困难的任务。财富500强中一个财务公司的网络管理经理说他们花了太多的时间用来查找问题，该经理补充说：“甚至技术人员已经把故障确定为网络中问题的情况下，也只有50%的情况真是网络的问题。有时我们不得不将所有人都派出去而只是为了找到问题在哪里”。
维护和管理
企业要求其网络，应用以及MIS的经理要保证那些与业务相关的关键应用必须在网络上平稳运行。确定影响应用性能的问题在哪里以及谁负责解决该问题是IT部门面临的十分费时且具有挑战性的工作。由于缺少有经验的人员和人力资源的限制，所有企业都希望以省时省力的方法来维护和管理响应时间。
[1-2]2操作系统编辑
操作系统的反映时间
在操作系统中，响应时间指用户发出请求或者指令到系统做出反应（响应）的时间。
系统响应时间包括两个方面：
时间长度和时间的易变性。用户响应时间应该适中，系统响应时间过长，用户就会感到不安和沮丧，而响应时间过短有时会造成用户加快操作节奏，从而导致错误。系统响应时间的易变性是指相对于平均响应时间的偏差。即使响应时间比较长，低的响应时间易变性也有助于用户建立稳定的节奏。因此在系统响应时间上坚持如下原则：
响应时间长度 界面设计
0-10 秒 鼠 标 显 示 成 为 沙 漏
10 到18 秒 由微帮助来显示处理进度
18 秒 以 上 显示处理窗口，或显示进度条
一个长时间的处理完成时 应给予完成警告信息
从用户角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。
响应时间过程分析
我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分，呈现时间，数据传输时间和系统处理时间。
呈现时间
其实主要说的浏览器对接收到数据的一个处理展示的过程。几年前大家都在用IE，如果页面显示比较慢，我们肯定不会怪罪IE，只会怪罪电信运营商的网速或被访问的系统（其实，大多情况我们不会考虑是被访问系统的问题）。现在chrome来了，我们会发现同一台电脑同一个网站，通过chrome去访问，页面的呈现速度会比IE略快。这是各种评测及大众用户的整体感受。当然，我个人感觉，opera浏览器的呈现速度最快，但它的显示效果一直不太好。
当然，我说这个呈现时间总不能全怪罪与浏览器的身上吧！当然还和承载它的操作系统有关，以及电脑硬件（比如cpu 内存）。假如你有超快的浏览器，如果是一台极其垃圾的电脑，我想你多打开两个网页就有可能使电脑卡掉。
数据传输时间
千万不要忽视数据传输时间。如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。（ps, 我10天前在china-pub订购的一本书现在还没到货！XXX）
拿我们系统的数据传输过程来说，我们发送一个请求需要时间，系统处理完后返回给我们也需要时间。初学性能测试工具的同学喜欢拿工具去测试互联网上的一些系统，甚至不懂性能的同学认为可以用性能测试工具将互联网上的一些网站压崩溃。貌似这一招比任何黑客攻击厉害多去。
那么，我觉得这些同学应该补补网络知识了，你的带宽是多少？互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。有没有考虑网络延迟？就算你的并发请求都能成功的发出，但到目的地的时候，已经不能叫并发了。
这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，也有特殊的性能测试需要在互联网中时行。它们重点不是求用户的最大的并发量。
系统处理时间
系统得到请求后对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间，因为前面的呈现时间和数据传输时间都我们不可控制的，用户使用的电脑及浏览器千差万别，用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短暂。
如果我们对系统的的处理进行分析和讲解的话，它会是一个非常庞大与复杂的过程。语言、语言框架、中间件，数据库、系统架构以及服务器系统。所以，想成为一个优秀的性能测试工程师我们的路还很长。
实际性的能测试
听了上面的分析，貌似每个过程都挺“浪费”时间，那么我们如何只测试系统的处理时间呢？
其实现在的测试工具都屏蔽呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，页不会将服务器的每个响应都向客户端呈现。
对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。
响应时间的定义：
响应时间
指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。
系统响应时间
应用系统从发出请求开始到客户端接收到响应所消耗的时间。需要注明的是，这样的定义完全是个人喜好。你可以提异议。
我们来看两种情况：
我要访问百度首页，发出了一个请求，百度开始给我返回页面数据，当搜索框与搜索按钮都已经返回到页面上了，但那个图标还在发送中。我不认为这个响应是完整的。必须把页面上的所有信息都返回给我才是完整的，我要的也是所有结果返回给我的时间。这种情况更符合“相应时间”的定义
某系统有一个信息查询功能，当我输入某条件查询时，可能要查询几百万条数据，如果数据库，要查询所有的数据并把所有的数据全部完整的返回给我。可能服务器要查询很久，而我的电脑全部接收这些数据也可能只直接挂掉。那么服务器可能只查询100条数据并把数据返回给我，当我点击“下一页”时，服务器再次查询并将第二页的数据返回给我。这种情况更符合“系统响应时间”的定义。
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。
合理的响应时间
在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。
也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
这里我们还要考虑一个使用频率的概念。
我最早安装windows系统可能要1个小时，我们为什么觉得这很正常，因为我们要很久才装一次系统，如果系统使用得当，可能一个系统用几年不用重装，假如，我们在系统上装个任何小软件都要这么长时间，那我们一定是无法忍受的。对于软件控来说，他们会时常安装各种新鲜有趣的软件进行使用。
对于一个税务报账系统，该系统的用户每月使用一次，一次花费3小时进行数据的录入，
当用户单击“提交”按钮后，即使系统在10分钟后才给出“处理成功”的消息，我们也觉得是可以接受的。
因此，在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。