互联网性能测试响应时间的标准

互联网性能标准

如果您指望我在这里给出一个关于性能好坏的行业标准，那我很遗憾地告诉您，没有这样的指导标准存在。不过，业内倒是有许多非正式的标准，试图对系统的性能好坏做出评价，尤其是针对基于B/S架构的应用程序。举例来说，您可能听说过“页面最小刷新时间”这种说法；我记得它从20秒迅速提高到8秒。当然了，用户和企业都希望系统能够“即时响应”，但这样的性能要求是很难达到的。

许多商业服务水平协议（SLA）涵盖基础设施的性能，而不是应用程序本身，他们往往只涉及具体的领域，如网络延迟或服务器可用性等。

以下的内容列出了在20世纪80年代后期，马丁（1988年）研究如何使用响应时间来衡量用户的工作效率的主要成果。最初的研究主要是基于绿屏软件文本的应用，但这些结论现在仍然具有参考意义。

超过15秒

出现这种情况，就基本排除了交互的可能性。对某些特定的应用程序，某些用户可以在一个终端前超过15秒的时间去等待一个查询结果的返回。然而，对于一个繁忙的呼叫中心运营商或期货事务商来说，超过15秒的延迟却是无法容忍的。如果真的发生了延迟，系统就应该设计成可以让用户转向其他操作，并且在后续的时间里继续请求响应。

超过4秒

这样的延迟一般对于一个要求最终用户保存在短暂记忆里的会话来说太长了。（这是最终用户的记忆，不是计算机的内存！）这样的延迟将妨碍解决问题的活动和破坏数据的录入。然而，当一个事务完成之后，4～15秒的延迟是可以忍受的。

2～4秒

超过2秒钟的延迟可以被这种需求的高度集中所抑制。当用户专注地去完成一项手头的任务时，终端的一个2～4秒左右的延迟看起来就似乎非常长了。同样地，在一个无关紧要的任务结束后，2～4秒钟的延迟是无关紧要的，又是可以接受的。当一个买家在输入了她的地址和信用卡号码后，让她等待2～4秒的时间，她也许可以接受。然而如果是在早先的阶段，当她正在比较不同产品的功能差异时，却又是不可容忍的。

低于2秒

当系统的用户需要记住几个响应信息时，此时的响应时间必须很短，如果要记住更为详细的信息，则要求就更高了，要求响应时间不能超过2秒。因此，对于那些较为复杂的活动，例如通过不同的规格尺寸去浏览相机产品时，2秒钟是一个很重要的响应时间限制。

亚秒

对于那些思想密集型的工作来说（比如写一本书），尤其是一个图形应用程序，响应时间要非常短，才能够保持用户的兴趣和吸引他长时间的关注。当一位艺术家将一幅图片拖拽到另一个位置时，程序必须能够立即对他下一次的创意给出响应。

0.1秒

在键盘上敲下一个按键，并在屏幕上出现相应的字符，或者用鼠标点击屏幕上的一个对象，这种响应几乎是瞬时的。很多电脑游戏都会要求非常快的交互响应。由此可见，关键的响应时间临界点是2秒。对于普通用户来说，响应时间超过2秒钟势必会对他们的使用造成一定的影响，因此，我们若将页面刷新时间定义为8秒，对于互联网的应用来说，肯定是不够理想的。

互联网的影响

互联网应用的“爆炸式（Big Bang）”增长为程序的快速应用提供了一个很好的发展方式。当前，许多（或者说绝大多数）的企业发现，依靠互联网来增加他们的收益是一个能想到的相当不错的方法。但是如果最终用户认为您的Web站点性能不好，那么他们的下一次点击很可能就会转到您的竞争对手的网站上去了。

另外，对于那些突发的需求高峰来说，用户界面的应用也是十分脆弱的；已经有相当多的知名零售公司发现了在每一年中的购物高峰期会出现性能问题。

总而言之，互联网的发展对于应用程序带来了商机也带来了性能方面的挑战。