jmeter介绍

1、Jmeter是apache组织开发的开源项目，设计之初是用于做性能测试的，同事它在实现对各种接口的调用方面做的比较成熟，因此常被用做接口功能测试和性能测试。
它能够很好的支持各种常见接口，如HTTP(s)、webservice、JDBC、JAVA、FTP等，并以多种形式展现测试结果。
2、开源免费，轻量级免安装，支持插件很多，功能也日趋完善，报表分析功能较弱。

jmeter安装及环境配置

1、安装jdk
Jmeter是依赖java环境的，所以要先安装jdk。
需要注意的是jmeter3.0以上的版本都需要jdk7以上才能支持，其他没啥特别的。
安装jdk并配置好环境变量。
2、安装jmeter
其实jmeter是免安装的，只需要下载解压即可。
安装包直接去jmeter官网下载即可，建议选择3.0或以上版本。下载后解压到非C盘的非中文目录即可。
3、配置jmeter环境变量
JMETER_HOME=D:\apache-jmeter-3.3\apache-jmeter-3.3
CLASSPATH=%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar; %JMETER_HOME%\lib\jorphan.jar;
4、启动jmeter
双击jmeter bin目录下的jmeter.bat，稍等一会儿能够正常打开如下界面，说明安装成功。

Dos窗口不可关闭，否则jmeter界面也就关闭了。

注意事项：
从上面命令行可以看到：Don`t use GUI mode for load testing!,only for Test creation and Test debugging.For load testing,use CLI Mode(was NON GUI):
大致意思是：不要使用GUI模式进行负载测试！，仅用于测试创建和测试调试。对于负载测试请使用CLI模式（非GUI）：

录制jmeter脚本

1、HTTP代理服务器
①、在TestPlan下创建线程组，右击TestPlan->线程（用户）->线程组

②、添加录制控制器，右击线程组->逻辑控制器->录制控制器

③、添加HTTP代理服务器，右击TestPlan->添加->非测试元件->HTTP代理服务器

④、在HTTP代理服务器的目标控制器处选择TestPlan->线程组->录制控制器

⑤、切换至Requests Filtering在排除模式中添加一列输入..(js|css|PNG|jpg|ico|png|gif).

⑥、在本地打开dos窗口输入ipconfig，IPv4 地址即为本地电脑的IP

⑦、在手机上打开设置->无线局域网，选择自己的wifi，选择配置代理->手动，输入服务器10.10.84.103，端口8888，点击【存储】。

⑧、在jmeter界面点击启动按钮

⑨、在手机上打开自己要录制的IP地址即可。

jmeter工具使用

1、创建线程组
在TestPlan下创建线程组，右击TestPlan->线程(用户)->线程组

2、线程组介绍

Ⅰ.名称：线程组自定义名称；
Ⅱ.注释：添加的一些备注说明信息，设置后，在目录树中鼠标悬停会显示配置的注释信息；
Ⅲ.在取样器错误后要执行的动作
①.继续：即取样器执行错误后，仍然继续执行后续的操作，直到整个线程完成；（默认）
②.Start Next Thread Loop：即取样器执行错误后，终止当前循环，进入下一个循环；
③.停止线程：即取样器执行错误后，停止当前线程；
④.停止测试：即取样器执行错误后，等待当前执行的采样器结束后停止执行测试；
⑤.stop test now：即取样器执行错误后，出现错误立刻终止测试；
Ⅳ.线程属性
①.线程数：即模拟的用户个数；
②.Ramp-Up Period（in seconds)：设置多少秒内完成所有的线程创建；—-该时间的设置需要根据项目需要去判断。如：线程数设置为10，时间设置为2—表示：两秒内启动10个线程，平均每秒启动5个线程；
③.循环次数：即线程执行的次数，1表示循环1次后停止；如果勾选永远，即线程会一直执行，如果配置了调度器，会受调度器配置影响。
④.Delay Thread creation until need：勾选代表线程将在需要的时候才构建；不勾选，代表线程组在开始的时候就被创建，需要时执行。
Ⅴ.调度器
只有在调度器勾选后，才可以进行配置；也只有勾选调度器后，配置的值才能生效；
①.持续时间：即线程的执行时间是多少秒，在达到时间后，将停止执行；
②.启动延迟：即手动开始运行线程后，jmeter自动延迟设置的时间才开始执行测试；—-注意：在勾选循环次数为永远，设置了持续时间时，会在持续时间达到后，停止测试；循环次数设置为非永远时，设置的调度时间无效，会在执行完循环次数后，停止测试。
3、配置元件
Ⅰ.在我们刚刚创建的线程组上右键【添加】–>【配置元件】–>【HTTP请求默认值】。

Ⅱ.配置我们需要进行测试的程序协议、地址和端口

当所有的接口测试的访问域名和端口都一样时，可以使用该元件，一旦服务器地址变更，只需要修改请求默认值即可。
Ⅲ.构造HTTP请求
在“线程组”右键【添加-】->【samlper】–>【HTTP 请求】设置我们需要测试的API的请求路径和数据。我这里是用的json

Ⅳ.在我们刚刚创建的线程组上右键【添加】–>【配置元件】–>【HTTP信息头管理器】。
因为我要传输的数据为json，所以设置一个 Content-Type:application/json

Ⅴ.在我们刚刚创建的线程组上右键【添加】–>【断言】–>【响应断言】。
根据响应的数据来判断请求是否正常。我在这里只判断的响应代码是否为200。还可以配置错误信息

Ⅵ.添加察看结果树
在我们刚刚创建的线程组上右键【添加】–>【监听器】–>【察看结果树】。

直接添加，然后点击运行按钮，若没有保存提示先保存；

点击【Yes】之后，弹出保存至某处的提示框，保存完成之后自动运行；

然后就可以看到结果了。

Ⅶ.添加Summary Report
在我们刚刚创建的线程组上右键【添加】–>【监听器】–>【Summary Report】。
直接添加，然后点击运行按钮就可以看到结果了。

Ⅷ.测试计划创建完成
记得点保存。
Ⅸ.执行测试计划
前面我们说过，执行测试计划不能用GUI，需要用命令行来执行。

我这里执行的命令为：
jmeter -n -t testplan/order.jmx -l testplan/result/result.txt -e -o testplan/webreport
说明：
testplan/RedisLock.jmx 为测试计划文件路径
testplan/result/result.txt 为测试结果文件路径
testplan/webreport 为web报告保存路径。
Web报告如下：

Ⅹ.写在最后
线程数量和循环次数将会影响最终的测试报告,请大家多多测试。
4、逻辑控制器
①、循环控制器：设置请求的循环次数或永远循环，可用于压力测试。

②、简单控制器：测试用例顺序执行。
就像他的名字一样，简单，可以理解为一个文件夹，就是分组用的，没有其他特殊功能，但相比不添加简单控制器，区别在于简单控制器可以被模块控制器所引用。
③、事务控制器：将多个请求放在同一个事务中。选中 Gegerate parent sample，则聚合报告中只显示事务控制器的数据，不会显示其中的各个请求的数据，反之则全部显示。

注：逻辑控制器可以组合使用。
5、脚本参数化
Ⅰ.在测试的过程中要用到参数化，比如说openId、crm_id等，此时需要添加一个csv数据文件设置即：CSV Data Set Config

Ⅱ.配置CSV Data Set Config

①.Filename: 指保存信息的文件目录，可以相对或者绝对路径。否则会在jmeter日志文件（jmeter.log目录位置）中提示：系统找不到指定文件，运行脚本后，登录失败。
②.File encoding: 保持默认。默认为ANSI
③.Variable Names: 给csv文件中各列起个名字（有多列时，用英文逗号隔开列名）便于后面引用
④.Delimiter:与 .csv文件的分隔符保持一致。如文件中使用的是逗号分隔，则填写逗号；如使用的是TAB，则填写\t；
⑤.Allow quoted data? :是否允许引用数据，—这个目前还未弄明白，设置成True或者False都能正常引用数据。
⑥.Recycle on EOF?:到了文件尾是否循环，True—继续从文件第一行开始读取，False—不再循环
⑦.Stop thread on EOF? :到了文件尾是否停止线程，True—停止，False—不停止，注：当Recycle on EOF设置为True时，此项设置无效。
⑧.Sharing mode:共享模式，All threads –所有线程，Current thread group—当前线程组，Current thread—当前线程。
² All threads：计划中所有线程，假如说有线程1到线程n (n>1)，线程1取了一次值后，线程2取值时，取到的是csv文件中的下一行，即与线程1取的不是同一行。
² Current thread group：当前线程组，假设有线程组A、线程组B，A组内有线程A1到线程An，线程组B内有线程B1到线程Bn。取之情况是：线程A1取到了第1行，线程A2取第2行，现在B1取第1行，线程B2取第2行。
² Current thread：当前线程。假设测试计划内有线程1到线程n (n>1)，则线程1取了第1行，线程2也取第1行。
Ⅲ.引用csv文件中的数据

①.找到需要传递参数的HTTP请求
②.将具体值改为变量引用，引用变量：${变量名}
Ⅳ.在察看结果树中，察看变量引用的具体值

6、json提取器
Ⅰ.在星妈优选的业务当中接口与接口之间存在依赖。所以需要将上一个接口的参数提取出来传给下一个参数这时用到了json提取器

Ⅱ.jmeter在察看结果树中点Text下拉框，选择JSON Path Tester

Ⅲ.比如要提取cart_token，$.cart_token提取cart_token

Ⅳ.提取出来的cart_token作为下一个接口的入参， ${cart_token} ![在这里插入图片描述](https://img-blog.csdnimg.cn/0e6edf265bb34b2b98bdfcbd800c6bf2.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY4NDU1OQ==,size_16,color_FFFFFF,t_70) 7、正则提取器 Ⅰ.正在表达式提取器介绍 ①.Apply to：应用范围 ②.要检查的响应字段：样本数据源。 ③.引用名称：其他地方引用时的变量名称，我这里写的phone，可自定义设置，引用方法：$ {引用名称}
④.正则表达式：数据提取器，()括号里为你要获取的的值。“mobilephone”:"( 相当于LR左边界， )","leaveamount"相当于LR右边界。而括号里\d+为正则表达式，用来匹配所需要获取的数据，何谓正则表达式文章末尾会附上说明
⑤.模板：$$对应正则表达式提取器类型。-1全部，0 随机，1第一个2第二个，以此类推，若只有一个正则一般就填写 $1$
⑥.匹配数字：正则表达式匹配数据的所有结果可以看做一个数组，匹配数字即可看做是数组的第几个元素。-1表示全部，0随机，1第一个，2第二个，以此类推。若只要获取到匹配的第一个值，则填写1
⑦.缺省值：匹配失败时的默认值。可以不写。若需用于后续逻辑判断，可简单写为 ERROR。
实例：在order接口提取出order_id

作为pay_payment的入参

附正则表达式说明：

通俗点来讲正则表达式就是用来匹配字符串的公式。比如正则表达式中\d+ 是来匹配1个或更多连续的数字。更多可自行百度了解。
8、断言（补充）

①、断言：对取样器返回的请求结果给出判断，是否正确。
②、用户可以使用断言来检查从服务器获得的响应内容，用来判断请求响应的结果是否如用户所期望的。
③、断言会影响作用域内的所有采样器。如果要让断言只影响某个采样器，需要将断言作为该采样器的子项。
④、断言中设置要测试的模式,则会对响应的内容(如http请求后,服务器返回的内容)进行与字符串进行匹配.如果返回的内容包括了字符串,则认为该次测试通过，否则就是失败。一般通过添加监听器来监听响应断言。

JMeter梯度加压之jp@gc – Stepping Thread Group

下载方法如下：
1、访问网网站：https://jmeter-plugins.org/downloads/old/
2、下载插件：

3、下载后需要解压，然后将JMeterPlugins-Standard.jar包放在jmeter安装目录的jmeter-3.0\lib\ext路径下，重新启动jemter即可。
使用方法：
1、添加线程组——jp@gc – Stepping Thread Group

2、Stepping Thread Group界面如下：

上图的各项意思：
This group will start 100 threads：设置线程组启动的线程总数为100个；
First,wait for N seconds：启动第一个线程之前，需要等待N秒；
Then start N threads：设置最开始时启动N个线程；
Next,add 10 threads every 30 seconds,using ramp-up 5 seconds：每隔30秒，启动10个线程，10个线程在5秒内启动完成；
Then hold load for 60 seconds：启动的线程总数达到最大值之后，再持续运行60秒；
Finally,stop 5 threads every 1 seconds：每秒停止5个线程；
3、在该Stepping Thread Group线程线下新建http请求等：

二、TPS和响应时间插件的下载：
两种方法：
（1）直接下载相差jar包放在包放在jmeter安装目录的jmeter-3.0\lib\ext路径下

(2)利用jmeter插件管理器：
1、下载插件管理器，包放在jmeter安装目录的jmeter-3.0\lib\ext路径下

2、

3、

JMeter监控工具之jp@gc – PerfMon Metrics Collector

1、打开jp@gc – PerfMon Metrics Collector插件，如图

2、输入服务器地址，端口为4444，如遇到端口冲突，可使用vim命令修改端口(端口随意，只要不冲突就行)，如图

注意：测试服务器性能时，要在服务器上放一个插件ServerAgent-2.2.3(放在服务器的任一位置，启动监测程序后运行JMeter)，Linux系统运行startAgent.sh，，windows系统运行startAgent.bat

3、如果没有启动服务器监测ServerAgent会报错，如图

4、如果在使用过程中出现了这个错误
java.lang.NoSuchMethodError: org.apache.jmeter.samplers.SampleSaveConfiguration.setFormatter(Ljava/text/DateFormat;)，此问题是因为所用JMeter版本过高不支持jp@gc – PerfMon Metrics Collector插件导致，可下载低版本的JMeter，比如JMeter 3.1。

5、指标说明

Jmeter连接Mysql

1、将mysql-connector-java-5.1.7-bin.jar放入Jmeter安装目录的bin文件夹中
2、在顶层目录<测试计划>中加载驱动

3、添加JDBC Connection Configuration

4、配置数据库信息
1）Variable Name不能为空
2）DataBase URL 格式为：jdbc:mysql://服务器ip:端口号/数据库
在数据库后加参数?allowMultiQueries=true,可同时执行多条mysql语句；否则报错
3）JDBC Driver Class：com.mysql.jdbc.Driver
4）输入数据库的用户名和密码

5、添加JDBC Request

6、添加变量和查询语句
变量名必须和JDBC Connection Configuration中的变量名保持一致

7、执行查询语句

8、参数说明：
Variable Name：数据库连接池的名字，需要与上面配置的JDBC Connection Configuration中 Variable Name Bound Pool的Variable Name相同
Query：填写的sql语句未尾不要加“;”
Parameter valus：参数值
Parameter types：参数类型
Variable names：保存sql语句返回结果的变量名
esult variable name：创建一个对象变量，保存所有返回的结果
Query timeout：查询超时时间
Handle result set：定义如何处理由callable statements语句返回的结果

jmeter使用实例

1、在windows和Linux环境下压测的区别：暂无
2、在Windows的dos窗口下进行压测
命令介绍：

参数介绍：

具体含义：

例如：jmeter -n -t test1.jmx -l logfile1.jtl -H 192.168.1.1 -P 8080

3、执行出的压测结果如何查看
①、打开Jmeter GUI界面
②、在测试计划下，添加对应的测试报告元件，此处演示，增加了：聚合报告、查看结果树、Summary Report测试报告
③、在所有数据写入一个文件，浏览中选择对应的日志文件
④、下面就会有对应的表格展示，具体见下图

4、在Linux环境下进行压测
Ⅰ.在Linux下安装jmeter：
①.将jmeter的压缩包上传到Linux下的/software目录下；
②…进入Linux下的/software目录，解压jmeter的压缩文件；
Ⅱ.将本地调试好的jmx文件上传至/software/jmeter/bin目录下：
Ⅲ.进入Linux下的//software/jmeter/bin目录下：
①.在命令行输入：
jmeter -n -t search.jmx -r -l search.jtl -e -o /tmp/apache-jmeter-5.1.1/resultReport：
大致意思是：执行search.jmx文件，生成search.jtl文件，再将search.jtl文件转换成报告；
②.执行完成之后，在命令行输入：tar zcvf resultReport.tar.gz ./resultReport：将报告打成压缩包，再下载到本地即可查看输出的报告；

jmeter常见报错及解决方法

1、错误一
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: connect timed out
查看Load time的时间要大于request设置的connect time out时间，所以抛出该异常。可能是由于服务端有较多请求正在处理（且处理时间较长），导致JMeter不能连接上服务器而产生的。
2、错误二
Java.NET.BindException: Address already in use: connect
原因：短时间内new socket操作很多,而socket.close()操作并不能立即释放绑定的端口,而是把端口设置为TIMEWAIT 状态,过段时间(默认240s)才释放,(用netstat -na可以看到),最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ,这段区间在1024-5000之间)
解决方法：在运行JMeter agent的机器上，添加注册表条目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort 65334
TcpTimedWaitDelay 30
3、错误三
java.lang.OutOfMemoryError: Java heap space(jmeter内存溢出)
原因：观察运行jmeter机器的内存，占用较高，超过了jmeter设置的内存上限。
解决方案：修改jmeter配置文件，调整内存可用的范围
修改/bin/jmeter.bat文件：找到这2行
set HEAP=-Xms256m -Xmx256m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
改为：
set HEAP=-Xms1024m –Xmx2048m（最大值不能超过系统内存的1/2）
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m
4、错误四
Response code: Non HTTP response code: java.net.SocketTimeoutException
Response message: Non HTTP response message: Read timed out
发生该错误时，jmeter已经连接上服务器，查看load time没有超过设定的request timeout时间，错误可能的原因是，服务器那边未处理该线程的请求，或者为保证服务能力，断掉了连接。
为了验证该猜想，持续大于半小时向服务器发送该并发数量的请求，一段时间后，request收到503的response，证明猜想。
5、错误五
Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:
原因：分布式测试时，server和agent之间的连接有问题。单个机器排查后，发现是某个agent机器安装了多个网卡，rmi远程的时候找的是虚拟机的网卡，导致连接失败。
解决方案：禁掉不使用的虚拟机网卡，测试之后再恢复。
jmeter脚本运行的过程中，服务器性能参数没有明显变化（CPU，内存，I/O），但request的响应时间很长。
原因：观察jmeter agent机器网络使用情况，网络使用持续达到带宽的限制峰值。request 发送的过程中pending在网络中，实际并发的request并没有同一时间到达服务器，所以服务器没有明显变化。
解决方案：提高jmeter agent机器网络带宽。
6、错误六
Connection timed out: connect
java.net.ConnectException: Connection timed out: connect
原因分析：
可能是因为端口号耗尽，一般一台服务器的端口号最多是65535个，建议使用该命令分别查看下压测机与服务器的端口使用情况，netstat -nat|grep -i 8080|wc -l，如果这个个数在6w左右，那可能就是端口号用尽,同时查看下大多数的端口状态，应该都是time_wait状态
解决方案：
如果是压测机，端口号用尽，那就增加压测机，使用jmeter分布式压测（jmeter默认开启keep_alive的）
如果数服务器，端口号用尽，最大的可能是服务器端开了短链接，把短链接配置变成长连接即可
因为如果服务器端是短链接，当jmeter每发起一个请求就会建立一次tcp三次握手，传输完数据后，连接其实没有关，连接状态是time_wait,下个请求来了，会重新开启一个新的端口，建立tcp三次握手，传输数据…，这样随着请求的越来越多，端口就会变得越来越少，所以端口很快耗尽，而且大多数端口都处于time_wait状态,如果服务器端也支持长连接，那么下次请求来了，就会在上次请求的通道上继续传输，端口使用率大大的降低，就有效的避免了端口耗尽问题。
原因：Jmeter默认禁掉了运行过程中每个request的具体response信息收集，只保留了status。
解决方法：修改jmeter.properties文件中Results file configuration。把所有和response相关False的项改为True。运行后将输出保存.jtl文件中。添加tree监听器，过滤只显示error request，可以查看到request和response的具体信息，从而判断出错原因。
tree report中显示socket time out相关的错误，如何判断是jmeter工具的原因，还是服务器的原因。

聚合报告

Ⅰ.聚合报告中有samples、averages、median、90%line、95%line、99%line、min、max、
error%、throughput、receivered KB/sec、sent KB/sec

1、Label
每个请求的名称，比如HTTP请求等
2、#Sample
发给服务器的请求数量
3、Average
单个请求的平均响应时间
4、Median
50%请求的响应时间
5、90%Line
90%请求响应时间
6、95%Line
95%请求响应时间
7、99%Line
99%请求的响应时间
8、Min
最小的响应时间
9、Max
最大的响应时间
10、Error%
错误率=错误的请求的数量/请求的总数
11、Throughput
吞吐量即表示每秒完成的请求数
12、Received KB/sec
每秒从服务器端接收到的数据量
13、Sent KB/sec
每秒从客户端发送的请求的数量

性能测试结果分析

Ⅰ、分析原则：
具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈->网络瓶颈（对局域网，可以不考虑）->服务器操作系统瓶颈（参数配置）->中间件瓶颈（参数配置、数据库、web服务器等）->应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压测（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
分段排除法很有效
分析的信息来源：
1)根据场景运行过程中的错误提示信息
2)根据测试结果收集到的监控指标数据
1、错误提示分析
分析实例：
①、Error: Failed to connect to server “payment.baihe.com”:[10060] Connection
②、Error: timed out Error: Server “user.baihe.com” has shut down the connection paematurely
分析：
A、应用服务死掉。
（小用户时，程序上的问题。程序上处理数据库的问题）
B、应用服务没有死。
（应用服务参数设置问题）
例：在许多客户端链接Weblogic应用服务器被拒绝，而在服务器没有错误显示，则有可能是Weblogic中的service元素的AcceptBacklog属性值设的过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25%
C、数据库的连接
（1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关））
Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太多
2、监控指标数据分析
①、最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，活出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发数用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
②、业务操作响应时间：
分析方案运行情况应从瓶颈事务响应时间和事务性能摘要图开始。使用”事务性能摘要”图，可以却低估在方案执行期间响应时间过长的事务。
细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络活服务器有关？
如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用”网络监视器”图确定导致性能瓶颈的网络问题。
2-5-8原则：简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个web站点，或者发起第二次请求。
3、服务器资源监控指标
内存
①、UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
②、Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set 计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆：
很高的换页率（high pageout rate）
进程进入不活动状态；
交换区所有磁盘的活动次数可高；
可高的全局系统CPU利用率；
内存不够出错（out of memory errors）
处理器
①、UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server，可接受的最大上限是80-85%，合理使用的范围在60%至70%。
②、Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆：
很慢的响应时间（slow response time）
CPU空闲时间为零（zero percent idle CPU）
过高的用户占用CPU时间（high percent user CPU）
过高的系统占用CPU时间（high percent system CPU）
长时间的由很长的运行进程队列（large run queue size sustained over time）
磁盘I/O
①、UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的磁盘系统。
②、Windows资源监控中，如果Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶颈。
I/O资源成为系统性能的瓶颈的征兆：
过高的磁盘利用率（high disk utilization）
太长的磁盘等待队列（large disk queue length）
等待磁盘I/O的时间所占的百分率太高（large percentage of time waiting for disk I/O）
太高的物理I/O速率：large physical I/O rate（not sufficient in itself）
过低的缓存命中率（low buffer cache hit ratio（not sufficient in itself））
太长的运行进程队列，但CPU却空闲（larage run queue with idle CPU）
4、数据库服务器
SQL Server数据库
①、SQL Server资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
②、如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
③、Number of Deadlocks/sec（死锁的数量/秒）：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该技术器的值必须为0。
④、Lock Requests/sec（锁请求/秒），通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库
①、如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
②、如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
③、如果日志缓存区申请的值较大，则应加大LOG_BUFFER参数的值。
④、如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。