性能指标之响应时间

前言：

响应时间常相见

对它了解有几何？

一、响应时间

在性能测试过程中，大家都接触过响应时间、TPS、并发用户、吞吐量、事务成功率、资源使用率等非功能指标，为了更好的了解这些指标，本文将介绍响应时间这个性能指标。

响应时间（Response Time）指的是从请求端发起请求开始，到请求端接收到服务器端的返回结束，这个过程所耗费的时间。它完整地记录了对应系统处理请求交易的时间。

如图一的访问请求，客户端的请求响应时间 = N1 + A1 + N2 + A2 +N3 + A3 + N4 + A4 + N5 + A5 + N6：

图一：请求流程图

一、响应时

二、孰快孰慢

响应时间对于普通用户而言，感知是请求返回的快慢；但对于我们IT人，就必须是具体的可度量的值，比如多少毫秒，多少秒。

但是响应时间的绝对值并不能直接反映系统的性能高低，性能的高低实际上取决于用户对该响应时间的接受程度。

比如贷记卡调用反欺诈系统，要求的响应时间是50ms以内；对于行内用户使用的P2客户端，大多数页面访问如果响应时间小于300ms，用户都很满意；响应时间1-3s，也还可以接受；但是如果响应时间超过3s，就要发点牢骚了；一旦超过10s，可能就难以接受了。但是对于大数据分析平台，比如进行一次客户评级趋势分析，需要耗时十几分钟甚至更长时间，由于这些操作频次少，价值大，因此这个响应时间对于客户来说是可以接受的。

虽然不同的场景对响应时间的要求各有差异，但是业界对于在线交易系统，还是有一个普遍的标准：早期是2/5/10秒原则，现如今随着技术的发展，用户的要求也提高了，逐渐朝1/3/5秒原则演变。

1/3/5秒原则：

在1s以内得到响应，用户会觉得系统响应很快，体验非常好；1-3秒得到响应，用户可以接收，体验还不错；3-5秒才响应，用户就感觉慢了，体验有点糟糕；一旦响应超过5秒，用户就会认为是个失败的体验，选择离开或重新发起请求。

因此响应时间没有绝对的快慢之分，建议参考业界的普遍原则和用户的实际需求来确定各应用系统对应的响应时间指标。

三、时间都去哪了

如果系统的响应时间超出了预期的指标值，就要引起我们的关注，需要去分析时间都去哪了？

参照图一请求流程图，我们对响应时间做个头脑风暴，大体切分如下：

图二：响应时间切分图

我们将交易请求的时间消耗，切分成展示耗时、网络传输耗时、应用处理耗时等部分。

展示耗时主要差别在浏览器、用户自身电脑配置的差异上；网络传输耗时，如果涉及广域网，大多情况都会有5ms-50ms的延时；如果是局域网普遍延时都在1ms以内，几乎可以忽略不计。为了避免网络延时，建议应用系统的服务器部署在同一局域网中。

不过这两个方面相对而言是比较不可控的，因此不是我们关注的重点。

我们关注的重点是应用系统处理耗时。一旦响应时间超时，我们着重从应用程序处理逻辑上分析：逻辑是否正确、算法的时间复杂度是否合理、日志是否写的太多了？同时监控服务器的资源使用情况，分析是否存在CPU使用率过高、存不足、IO繁忙等现象？根据实际工作经验，通常情况，最长的时间消耗是在数据库的读取上。

一旦定位出耗时长是由于数据库操作导致的，重点则是分析SQL语句，分析数据库的表、索引设计是否合理，表关联是否正确，是否存在扫描大量非必要的数据造成IO读取的浪费，以及SQL实现算法是否可优化等。

可以说每个步骤的具体分析过程，包含着很多知识点，也充满了乐趣，推动着我们不断地去学习和实践。

四、结束语

根据以上介绍和耗时切分的分享，实际工作中依此进行层层深入的分析，响应时间耗时必将大白于天下。通过本文介绍不知道你是否对响应时间有了更深入的了解？欢迎大家互相交流探讨。

厦门开发中心测试与推广支持处 系统与非功能小组出品

作者：林宜领

编辑：方妍