现象描述
不管是性能测试中，还是生产环境中，经常会遇到响应时间过长的问题。
响应时间是性能评估的一个重要指标，会对最终用户产生直接影响，一个产品是快是慢，响应时间是最直观的感受。
因此面对响应时间长的问题，一定想尽办法消灭它。
以下定位方法是针对比较典型的nginx+tomcat应用架构。
排查思路及方法说明
常见有两种表现：偶现极少量的请求出现响应时间偏长，或者会有大量、批量的请求响应时间长。
对偶然出现的少量响应时间长的问题，可能是外部影响、网络异常等造成。
偶然出现少量响应时间过长时，可以排查以下几个方面来定位问题，
查看当时服务器日志是否有错误；
检查服务器资源使用情况是否正常，load average、CPU使用率(尤其是单核CPU)是否有飙高现象；
检查是否出现磁盘短暂负载较高，比如iostat util%飙高等；
确认当时网络情况是否正常，是否有网络丢包等现象。
以上排查建议在有全面监控的基础上进行，偶现问题比较难定位，有全面的监控数据进行排查就方便多了。
案例1：单核CPU使用率高导致偶现响应时间长
某产品线上出现少量的响应时间长的问题，定位结果发现是两个CPU密集型服务部署在同一台机器上，
其中一个服务会使得单个CPU使用率100%，导致另一个服务出现少量请求响应慢。解决办法是服务隔离。
如果出现比较多的响应时间过长，首先要排查所有服务器是否存在资源使用瓶颈，
如CPU使用率高、单核CPU使用率高、内存使用是否正常、是否有频繁FullGC、磁盘IO压力情况、网路时延情况等。
如果不能通过以上检查发现问题所在，那就要逐步分析是系统架构中哪个环节导致的问题。
nginx排查
首先排查nginx access.log日志，分析响应时间可能慢在哪里。
log_format中定义了$request_time字段，它指的是从接受用户请求数据到发送完回复数据的时间。
那究竟是慢在了nginx还是上游服务器？
log_format同时提供了$upstream_response_time字段，它是指从nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间。
那就是说：
如果两者相差很大，也即是$upstream_response_time数值比较小，则需要查看nginx模块配置或nginx与客户端的网络是否有性能瓶颈了。
如果r e q u e s t t i m e 与 request_time与requestt​ime与upstream_response_time相差不大，则可能是nginx连接上游服务器比较慢，或者上游服务比较慢，需要进入下一步应用层排查。
案例2：nginx日志排查出网络问题
一线上产品出现某个操作响应时间30%以上都大于2s，通过分析access.log发现r e q u e s t t i m e 与 request_time与requestt​ime与upstream_response_time相差不大，
进一步检查nginx的配置，以及nginx服务器所在的交换机流量发现，nginx所在交换机流量基本快跑满了，导致nginx返回数据较慢。
nginx层排查除了以上日志排查外，还需要关注nginx本身的配置，比如nginx worker_connections设置过小会导致响应时间长，tps上不去，具体可参考上一期《tps上不去》。
应用层排查
排除Nginx层的问题，那要着重定位应用层自身代码、或者第三方调用、或者数据库等其它依赖服务是否存在响应慢的情况。
首先确认是否存在以下问题：
确认应用服务是否有某些线程CPU使用率高，通过top -H可以方便实时查看
确认线程是否存在异常状态，如频繁blocked、死锁等，推荐使用visualVM、Jconsole、jstack查看线程状态，进行线程dump
连接数检查，应用层连接数设置过小，会导致响应时间长，tps上不去，可以参考上一期《tps上不去》问题
如果有产品内部监控，如典型业务调用的处理时间、慢操作日志监控，那就比较方便了
如果很不幸，监控数据很少，且现有数据难以分析，那推荐两个百试不爽的分析工具，Nprofile和Btrace。
Btrace在线调试神器
BTrace 是一款利用hotSpot虚拟机可以动态替换class的特点而完成的，可以对online的程序动态的改变类的行为, 进而进行线上调试的一个工具。
也就是说可以不需要重启服务可以直接在线调试分析。关于Btrace的教程随意搜索就能找到很多。
案例3：Btrace在线分析
生产环境出现某种请求有30%的比例响应时间比较长，需要定位具体是哪个接口或调用响应时间长。
1、首先要了解应用层的调用关系，我们对com.netease.XXX.usercenter.web.dwr.YYYBean进行跟踪，完成Btrace脚本：
@BTrace
public class LessonLearnRecordServiceImpl {
@TLS
static long beginTime;
@OnMethod(clazz = "/com.netease.XXX.usercenter.web.dwr.YYYBean/", method = "/.+/")
public static void traceExecuteBegin() {// 在方法btrace.test.MyBtraceTest.execute()执行之前进行监控。
beginTime = timeMillis();
// 监控行为是记录一个开始时间。
}
// OnMethod代表运行一个方法的时候进行监控，location @Location(Kind.RETURN)代表在方法返回的时候触发监控行为。
@SuppressWarnings("deprecation")
@OnMethod(
clazz = "/com.netease.XXX.usercenter.web.dwr.YYYBean/",
method = "/.+/",
location = @Location(Kind.RETURN)
)
public static void traceExcute() {
// 监控行为是根据开始时间计算出方法运行时间。
print(strcat("entered ", name(probeClass())));
print(strcat(".", probeMethod()));
println(strcat(" taken : ",strcat(str(timeMillis() - beginTime), "ms")));
}
}
2、获取服务的进程PID，启动Btrace agent：btrace
查看生成的日志如下：
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 818ms
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 619ms
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 930ms
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 613ms
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 515ms
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 716ms
观察日志发现updateVideoTime方法大部分调用时间大于500ms，基本能判断是该方法需要进行性能优化。
Nprofile分析调用热点
Nprofile也即是AJprofile，是由何卓斌开发的一个自身开销比较小，可以profile调用时间和调用热点的小工具。
原理是在需要跟踪的函数调用前后通过AOP调用一些计时的代码，并进行一些简单的统计处理。
使用说明参考:http://doc.hz.netease.com/pages/viewpage.action?pageId=25690763(内部资料)
案例4: 循环调用导致响应时间长
某web应用，一个Http get请求，性能测试最高tps240，平均响应时间接近1s，CPU使用偏高。不满足性能测试通过条件。
对该接口进行profile：
可以发现一次getMyCourse，会有十几次的getFirstLesson和getLastestLearnedLesson调用。
经过确认，确实存在无用的循环调用问题。解决后性能有30%以上的提升。
Nprofile堪称利器，在性能问题分析和定位中非常有效，且比Jprofiler轻便，开销小，对性能测试结果影响小。
数据库层排查
通常web应用会有大量的数据库操作，数据库性能对web应用的性能表现至关重要。如果应用层的分析发现大量线程
等待数据库的响应，就需要对数据库层进行排查。最常见的数据库性能问题有：
索引缺失或者索引建的不合理，sql语句不合理导致没有走索引，进而导致SQL的执行时间长
SQL语句自身写的有问题，导致执行时间比较长
锁等待和锁超时导致事务回滚以致于响应时间很长
数据库的配置不合理，例如最大并发连接过小，bufferpool的设置过小等引起的性能问题
案例5：未创建索引导致响应时间长，CPU飙高
某接口tps只有150时，cpu使用率飚满，且响应时间大于1s。通过Nprofile分析，
发现其中一个方法调用消耗了99%的CPU调用，该方法主要是进行数据库读操作，检查数据库发现未创建索引。
解决后tps上升一倍，响应时间下降到250ms左右。
数据层性能问题可以通过Mysql监控、或mysql-slow.log进一步详细分析。

现象描述
不管是性能测试中，还是生产环境中，经常会遇到响应时间过长的问题。

响应时间是性能评估的一个重要指标，会对最终用户产生直接影响，一个产品是快是慢，响应时间是最直观的感受。

因此面对响应时间长的问题，一定想尽办法消灭它。

以下定位方法是针对比较典型的nginx+tomcat应用架构。
排查思路及方法说明
常见有两种表现：偶现极少量的请求出现响应时间偏长，或者会有大量、批量的请求响应时间长。

对偶然出现的少量响应时间长的问题，可能是外部影响、网络异常等造成。
偶然出现少量响应时间过长时，可以排查以下几个方面来定位问题，
查看当时服务器日志是否有错误；
检查服务器资源使用情况是否正常，load average、CPU使用率（尤其是单核CPU）是否有飙高现象；
检查是否出现磁盘短暂负载较高，比如iostat util%飙高等；
确认当时网络情况是否正常，是否有网络丢包等现象。

以上排查建议在有全面监控的基础上进行，偶现问题比较难定位，有全面的监控数据进行排查就方便多了。
案例1：单核CPU使用率高导致偶现响应时间长

某产品线上出现少量的响应时间长的问题，定位结果发现是两个CPU密集型服务部署在同一台机器上，

其中一个服务会使得单个CPU使用率100%，导致另一个服务出现少量请求响应慢。解决办法是服务隔离。
如果出现比较多的响应时间过长，首先要排查所有服务器是否存在资源使用瓶颈，

如CPU使用率高、单核CPU使用率高、内存使用是否正常、是否有频繁FullGC、磁盘IO压力情况、网路时延情况等。

如果不能通过以上检查发现问题所在，那就要逐步分析是系统架构中哪个环节导致的问题。
nginx排查
首先排查nginx access.log日志，分析响应时间可能慢在哪里。
log_format中定义了$request_time字段，它指的是从接受用户请求数据到发送完回复数据的时间。

那究竟是慢在了nginx还是上游服务器？
log_format同时提供了$upstream_response_time字段，它是指从nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间。

那就是说：

如果两者相差很大，也即是$upstream_response_time数值比较小，则需要查看nginx模块配置或nginx与客户端的网络是否有性能瓶颈了。
如果$request_time与$upstream_response_time相差不大，则可能是nginx连接上游服务器比较慢，或者上游服务比较慢，需要进入下一步应用层排查。

案例2：nginx日志排查出网络问题
一线上产品出现某个操作响应时间30%以上都大于2s，通过分析access.log发现$request_time与$upstream_response_time相差不大，

进一步检查nginx的配置，以及nginx服务器所在的交换机流量发现，nginx所在交换机流量基本快跑满了，导致nginx返回数据较慢。
nginx层排查除了以上日志排查外，还需要关注nginx本身的配置，比如nginx worker_connections设置过小会导致响应时间长，tps上不去，具体可参考上一期《tps上不去》。
应用层排查
排除Nginx层的问题，那要着重定位应用层自身代码、或者第三方调用、或者数据库等其它依赖服务是否存在响应慢的情况。

首先确认是否存在以下问题：
确认应用服务是否有某些线程CPU使用率高，通过top -H可以方便实时查看
确认线程是否存在异常状态，如频繁blocked、死锁等，推荐使用visualVM、Jconsole、jstack查看线程状态，进行线程dump
连接数检查，应用层连接数设置过小，会导致响应时间长，tps上不去，可以参考上一期《tps上不去》问题
如果有产品内部监控，如典型业务调用的处理时间、慢操作日志监控，那就比较方便了
如果很不幸，监控数据很少，且现有数据难以分析，那推荐两个百试不爽的分析工具，Nprofile和Btrace。
Btrace在线调试神器
BTrace 是一款利用hotSpot虚拟机可以动态替换class的特点而完成的，可以对online的程序动态的改变类的行为, 进而进行线上调试的一个工具。

也就是说可以不需要重启服务可以直接在线调试分析。关于Btrace的教程随意搜索就能找到很多。
案例3：Btrace在线分析

生产环境出现某种请求有30%的比例响应时间比较长，需要定位具体是哪个接口或调用响应时间长。

1、首先要了解应用层的调用关系，我们对com.netease.XXX.usercenter.web.dwr.YYYBean进行跟踪，完成Btrace脚本：
@BTrace

public class LessonLearnRecordServiceImpl {
@TLS
static long beginTime;

@OnMethod(clazz = "/com.netease.XXX.usercenter.web.dwr.YYYBean/", method = "/.+/")
public static void traceExecuteBegin() {// 在方法btrace.test.MyBtraceTest.execute()执行之前进行监控。
    beginTime = timeMillis();
    // 监控行为是记录一个开始时间。
}

// OnMethod代表运行一个方法的时候进行监控，location @Location(Kind.RETURN)代表在方法返回的时候触发监控行为。
@SuppressWarnings("deprecation")
@OnMethod(
clazz = "/com.netease.XXX.usercenter.web.dwr.YYYBean/",
method = "/.+/",
location = @Location(Kind.RETURN)
)
public static void traceExcute() {
// 监控行为是根据开始时间计算出方法运行时间。
print(strcat("entered ", name(probeClass())));
print(strcat(".", probeMethod()));
println(strcat(" taken : ",strcat(str(timeMillis() - beginTime), "ms")));
}

}

2、获取服务的进程PID，启动Btrace agent：btrace

查看生成的日志如下：
entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 818ms

entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 619ms

entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 930ms

entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 613ms

entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 515ms

entered com.netease.XXX.usercenter.web.dwr.YYYBean.updateVideoTime taken : 716ms

观察日志发现updateVideoTime方法大部分调用时间大于500ms，基本能判断是该方法需要进行性能优化。
Nprofile分析调用热点
Nprofile也即是AJprofile，是由何卓斌开发的一个自身开销比较小，可以profile调用时间和调用热点的小工具。

原理是在需要跟踪的函数调用前后通过AOP调用一些计时的代码，并进行一些简单的统计处理。

使用说明参考:http://doc.hz.netease.com/pages/viewpage.action?pageId=25690763(内部资料)
案例4: 循环调用导致响应时间长

某web应用，一个Http get请求，性能测试最高tps240，平均响应时间接近1s，CPU使用偏高。不满足性能测试通过条件。

对该接口进行profile：
可以发现一次getMyCourse，会有十几次的getFirstLesson和getLastestLearnedLesson调用。

经过确认，确实存在无用的循环调用问题。解决后性能有30%以上的提升。
Nprofile堪称利器，在性能问题分析和定位中非常有效，且比Jprofiler轻便，开销小，对性能测试结果影响小。
数据库层排查
通常web应用会有大量的数据库操作，数据库性能对web应用的性能表现至关重要。如果应用层的分析发现大量线程

等待数据库的响应，就需要对数据库层进行排查。最常见的数据库性能问题有：
索引缺失或者索引建的不合理，sql语句不合理导致没有走索引，进而导致SQL的执行时间长
SQL语句自身写的有问题，导致执行时间比较长
锁等待和锁超时导致事务回滚以致于响应时间很长
数据库的配置不合理，例如最大并发连接过小，bufferpool的设置过小等引起的性能问题
案例5：未创建索引导致响应时间长，CPU飙高

某接口tps只有150时，cpu使用率飚满，且响应时间大于1s。通过Nprofile分析，
发现其中一个方法调用消耗了99%的CPU调用，该方法主要是进行数据库读操作，检查数据库发现未创建索引。

解决后tps上升一倍，响应时间下降到250ms左右。
数据层性能问题可以通过Mysql监控、或mysql-slow.log进一步详细分析。

一、动态过程和稳态过程
1、动态过程（过渡过程或瞬态过程）

在典型输入信号作用下，系统输出量从初始状态到最终状态的响应过程。当r(t)=1(t)时，系统响应可能为：





2、稳态过程（稳态响应）

在典型输入信号作用下，当t→∞时的系统输出。它表征系统输出最终复现输入量的程度，用稳态性能指标描述

3、动态性能与稳态性能

动态性能：阶跃输入对系统来说是最严峻的工作状态。如果对于阶跃输入，系统的动态性能满足要求，那么系统在其他形式输入时，动态性能通常仍能满足要求
稳态性能：描述稳态性能的一种性能指标是稳态误差。通常在阶跃函数、斜坡函数或加速度函数作用下计算



二、时域性能指标
1、动态指标
在阶跃输入作用下，测定或计算机系统的动态性能



上升时间tr：震荡——第一次上升到终值所需时间

​                       非震荡——从终值的10%上升到终值的90%所需的时间


延迟时间td：指响应曲线第一次达到其稳态值一半时所需的时间


峰值时间tp：响应超过其稳态值到达第一个峰值所需要的时间


调节时间ts：响应到达并保持在【终值±5%终值】（或±2%）内所需的最短时间


超调量σ：响应的最大偏离量h(tp)与稳态值h(∞)之差的百分比



tr、tp——评价系统起始段的响应速度
σ——评价系统的阻尼程度
ts——评价系统整个过渡过程的响应程度，是速度和阻尼程度的综合指标


2、稳态指标


描述系统稳态性能的一种性能指标，通常在典型输入作用下进行测定或计算。单位阶跃输入下的稳态误差也称为余差
注意：性能指标是就稳定系统而言的


三、一阶系统响应


等价关系：系统对输入信号导数（积分）的响应，就等于系统对该输入信号响应的导数（积分）
注意：积分常数由零初始条件确定。该结论可推广至高阶系统


跟踪能力：阶跃输入：无稳态误差，既能够跟踪阶跃信号，跟踪速度取决于T
​                   斜坡输入：有位置误差，且稳态误差等于时间常数T
​                   加速度输入：稳态误差无穷大，即一阶系统不能跟踪加速度信号




四、二阶系统响应

1、二阶系统传递函数的标准形式
典型结构的二阶系统如下图：



其前向通道传函：



开环传函：



闭环传函：



$\Phi_{(s)}$为典型二阶系统传递函数的标准形式。$\xi$ 为阻尼比，$\omega _{n}$ 为无阻尼自然震荡频率。这两个参数称为二阶系统的特征参数。
系统的特征方程：



特征根 ：



注意当 $\xi$不同时，特征根有不同的形式，系统的阶跃响应形式也不同，它的阶跃响应有振荡和非振荡两种情况。



上面提到了极点（特征根）位置，说下系统稳定性的判别方法。当系统的极点位置都在复平面的左半平面时，则该系统稳定。 从上图看出只有当$\xi=0$ 时系统是不稳定的。
2、当 $0<\xi<1$ 欠阻尼衰减振荡下的二阶系统性能指标
单位阶跃输入信号下的性能指标 ：
超调量：



调节时间ts： $t_{s}=\frac{3.5}{\zeta \omega _{n}}$
由上可见，如果无阻尼振荡频率 $\omega _{n}$一定的话，那么二阶系统的动态性能由 $\zeta$决定。

工程上有个最佳阻尼系数  $\zeta=0.707=\frac{\sqrt{2}}{2}$。这个参数怎么确定的呢，往下分析。
2.1、不同阻尼比对二阶系统动态性能的影响。
例如：一个典型的二阶系统传函 $\Phi _{(s)}=\frac{\omega_{n} ^{2}}{s^{2}+2\zeta\omega _{n} s+\omega_{n} ^{2}}$ ,我们令 $\omega_{n}=4$，看 $\xi$为不同值的单位阶跃响应下的动态时间曲线。用MATLAB仿真下：



仿真程序如下：
>> step(tf(4^2,[1,2*0*4,4^2]));
axis([0 3 0 2.5])
hold on
step(tf(4^2,[1,2*1*4,4^2]));
axis([0 3 0 2.5])
hold on
step(tf(4^2,[1,2*1.5*4,4^2]));
axis([0 3 0 2.5])
hold on
step(tf(4^2,[1,2*0.8*4,4^2]));
axis([0 3 0 2.5])
hold on
step(tf(4^2,[1,2*0.707*4,4^2]));
axis([0 3 0 2.5])
hold on
step(tf(4^2,[1,2*0.5*4,4^2]));
axis([0 3 0 2.5])
hold on

可以看出当 $\zeta=0.707$ 动态性能比较好，所以在工程上对二阶系统的整定为 $\zeta=0.707$。
如果把典型结构的二阶系统化成尾1型：


那么K为开环放大系数，T表示时间常数。 上图在陈伯时的运动控制系统中被称为典型I型二阶系统。
对应二阶系统的闭环传函标准型为：



则 $w_{n}=\sqrt{\frac{k}{T}}$，   $\xi=\frac{1}{2}\sqrt{\frac{1}{KT}}$  ，如果工程整定 $\zeta=0.707$ 。则 KT=0.5 。
注意：

按KT=0.5整定时，那么这个系统就是稳定的，并且在超调和稳定时间上都是最优的。

其实在KT=0.5不变的情况下，K值越大，系统的带宽也大，响应越快；
当KT=0.5时，系统的响应是有点超调的，如果对于一个不能有超调的系统来说，可以设置KT值小点，（比如KT=0.4；）牺牲点响应时间，来提高系统的稳定性。其实也就是调大点阻尼比来提高系统的稳定性。减小超调。
系统的KT值过大（阻尼比过小），那么这个系统就容易出现震荡。
其实为获得较好的动稳态性能，不管是几阶系统常常取阻尼比 $\xi=0.707$  对应的参数，作为系统的整定

在时域分析中系统的几个性能指标，如上升时间，峰值时间，调节时间，超调量都与我们讨论的自然震荡频率（$w_{n}$）和阻尼比（$\xi$）这两个特征参数相关。