Java web应用性能分析之性能指标【响应时间】

前面几篇发出来，发现漏了一个标准说明。当我们谈论应用慢时，这个慢的指标是啥？怎么衡量的？从用户体验来讲，一个页面展示在3秒完成，用户还能接受，超过3秒就会影响用户体验，用户就会感觉到页面打开慢。这个3秒即响应时间。页面加载慢，和服务器资源、前端web服务器配置、后端接口响应、前端代码都有关。

这里我们主要是从前端代码和前端web服务器配置来分析。

上面提到的“3秒”，即“响应时间”，或者叫“用户感知时间”。

响应时间（用户感知时间）

响应时间是指系统对请求作出响应的时间。这个时间是指用户从软件客户端发出请求到用户接收到页面返回数据的整个过程所需要的时间，包括各种中间件(如服务器、数据库等)的处理时间。

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

客户感受的响应时间（即用户感知时间） = 客户端响应时间（即UI渲染时间）+服务器端响应时间（即服务端处理时间）+网络响应时间（即网络延迟）。

假设：要在1s内完成页面渲染展示。如上图所展示，实际有600ms的强制网络开销并且你无法做任何事，而只有400ms的时间去做服务器优化与客户端的性能优化。

再以“用户感知级别：可用”为参考的目标性能指标，可以得到“总时间”为1.0s ~ 2.0s。这里取一个平均值1.5s（即1500ms），再减去网络延迟开销（n），剩下的就是可以实际参考的【性能优化的目标时间】了。

这里，通过Google官方分析大量用户与网站数据实际得出的结论是：页面布局渲染的理想时间为200ms。如图：

google page-speed tool

所以需要为上面公式中“UI渲染”这一项分配200ms。

通常情况下网络延迟没有确定的时间，而且移动网络与非移动网络的延迟差距也不小。做为性能要求很高的游戏服务器的网络延迟开销一般控制在200ms~400ms以内。这里给网络开销取一个相对严苛的时间数值：400ms。

通过以上这些数据不难推出一个公式：

总时间 - UI性能 - 网络延迟 = 服务端处理时间

把各部分调研出的目标时间带入公式最后得到：

(总时间)1500ms - (UI性能)200ms - (网络延迟)400ms = (服务端处理时间)900ms

[服务端处理时间]时间 = 900ms

也就是说，服务端处理时间最大响应的时间在900ms以内（即一般api接口响应时间不能超过900ms），才是可以满足基本可用的实际用户交互服务目标。

API响应时间分级: ：< 100ms 流畅：100ms ~ 200ms 可用：500ms ~ 1000ms 卡顿：2000ms ~ 5000ms 阻塞：> 5000ms [超时或不可用]

然而，由于网络连接性能有很大差异，因此，只考虑网页性能中与网络无关的方面：服务器配置、网页的HTML结构及其所用的外部资源（例如，图片、JavaScript和CSS）。实施这些建议应该能改进网页的相对性能。但网页的绝对性能将仍取决于用户的网络连接。

页面加载耗时

从用户输入地址或点击操作触发浏览器发出加载请求开始。请求通过网络到达服务器，服务返回页面描述信息(html文件)给浏览器。然后，浏览器解析html页面文件，得到了需要加载逻辑脚本(js文件)，样式描述文件(css文件)，图片文件等内容后，继续向服务器请求这些内容资源，服务器返回指定的目标资源。（如下图）