|—1、性能测试简介

指通过自动化的测试工具]模拟多种正常、[峰值]以及[异常负载条件来对系统的各项性能指标进行测试

|—1.1、对性能的认识

从用户的角度：

从开发的角度：

从系统管理员的角度：

那么？测试应该关注哪些呢？

测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面：

• - 测试人员需要考虑全面的性能，包括[用户、开发、管理员]等各个视角的性能。

• - 测试人员在做性能测试时除开要关注表面的现象如[响应时间]，也需要关注本质，比如用户看不到的[服务器资料利用率]，架构设计是否合理？代码是否合理等方方面面。

|—2、目的

• - 1. 系统的稳定/可靠运营---长时间、高负载测试下交易成功率、资源稳定性。

• - 2. 成本的优化配置--最优CPU数量、内存数量、服务器数量、专线带宽

• - 3. 给用户带来更好的体验，运行速度快（平均响应时间），流畅（占用我们的硬件资源少）

• - 4. 判断目前系统的性能瓶颈，一到关键时候比较卡，一般是人多的时候比较卡（并发）

• - 5. 系统应用能够适应未来的业务增长

|—3、性能测试工具

• - 1. JMeter

• - 2. LR(LoadRunner)

• - 3. postman

• - 4. SoupUI

|—4、性能测试的分类

• - 1. 并发测试

• - 2. 压力测试（强度测试)

• - 3. 疲劳测试

• - 4. 负载测试

• - 5. 配置测试

• - 6. 可靠性测试

|—4.1、并发测试

并发测试就是模拟一群人同一时间做事并发测试就是对被测系统的并发处理能力进行考察的一种测试手段（可以是某个功能模块或数据记录）一般都是看在绝对并发的情况下，系统能承载多大的并发量，是否存在死锁或其者他性能问题。或者在一定的并发量下，系统的响应时间是否是可接受的。

特点：

- 1、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。

- 2、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

- 1、绝对并发：

一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。

比如：12306春运期间的放票，一到放票开始，N多的用户在同一时间点对服务器发起买票的请求。比如8:00放票时段，有100万用户对12306发起了买票的请求。

- 2、非绝对并发：

另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。在一定的并发量下，***系统的响应时间是否是可接受的

|—4.2、压力测试

压力测试是在接近用户承载量极限以下一些（还不足以把系统压垮的用户量），较长时间不间断执行的性能测试，是检查系统稳定性，系统性能瓶颈的一种常用场景。

压测时间，一般场景都运行10-15分钟。如果是疲劳测试，可以压一天或一周，根据实际情况来定。

压力测试分两种场景：

- 一种是单场景，压一个接口的

- 第二种是混合场景，多个有关联的接口。

|—4.3、疲劳测试

疲劳测试是采用系统稳定运行情况下能够支持的最大[并发用户数]，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

一般情况下以服务器能够正常稳定响应请求的最大[并发用户数]进行一定时间的疲劳测试，获取交易执行指标数据和监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下[并发用户数]为基础，进行一定时间的疲劳测试。

|—4.4、负载测试

就是一批一批的加用户，待到当前在线用户执行稳定后，再加下一批的用户，像这样不停的持续加压，直至系统性能明显下降或系统崩溃为止。是测试系统用户上限，查找系统性能瓶颈的重要手段。通常在还不知道系统能承载多大业务量的情况下，为找到用户承载量极限或为了快速定位系统性能瓶颈时，会采用此种方式进行测试。

特点：

- 1、这种性能测试方法的主要目的是找到系统处理能力的极限。

- 2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。

- 3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。

|—4.5、配置测试

配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。

也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。

特点：

- 1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。

- 2、这种性能测试方法一般在对系统性能状况有初步了解后进行。

- 3、这种性能测试方法一般用于性能调优和规划能力。

|—4.6、可靠性测试

在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。

特点：

- 1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。

- 2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）

- 3、测试过程中需要关注系统的运行状况。

备注：一般企业中作得比价多是并发测试，压力测试，根据具体需求场景，有必要的话也会适当的作一些负载测试，疲劳测试。

和负载测试的概念比较接近的是压力测试。通俗地讲，压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

最后再说下疲劳强度测试。其实疲劳强度测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，疲劳强度测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。

|—5、性能测试指标

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。

|—5.1、业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：

• 　1.并发用户数

• 　2.事务吞吐率（TPS/RPS）

• 　3.事务平均响应时间

• 　4.事务成功率

从以下几个方面来评定指标是否达标

- ①.给出产品性能的主要指标，如在100000记录中查询一个特定数据的时间为0.5秒；

- ②.以某个已发布的版本为基线，如比上一个版本的性能提高30-50%；

- ③.和竞争对手的同类产品比较。

|—5.2、服务器的性能指标——nmon工具

- ①.CPU利用率；

- ②.内存占用率；  考虑是否存在内存泄漏的情况。

- ③.磁盘I/O ；

- ④.网络   网络带宽

|—6、性能测试专业术语

性能测试要求的指标:性能测试需求上有说明，SE规定了要我们做哪些业务的性能，像：登录，注册，下单，查询，添加购物车等，项目组只要求我们做了并发，压测这块。

|—6.1、并发数

一、经典公式1：

   一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据

  1）平均并发用户数为 C = nL/T

  2）并发用户数峰值 C‘ = C + 3*根号C

​    C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度

​    C’是并发用户数峰值

举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。

平均并发用户数为 C = 400*4/8=200

并发用户数峰值  C`= 200 + 3*根号200=243

举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。

  则一个月最后一周的平均并发用户数为（朝九晚五）：

  n = 170000*0.5*0.7/5 = 11900

  C= 11900*5/60/8 = 124

|—6.2、响应时间（90%用户的平均响应时间）

0.几秒算好的，1.几秒都算比较好的，<=3秒 都算正常，>3秒，分析下。超过5s以上性能是不达标。

|—6.3、吞吐率

100/sec

吞吐量计算为：F = Vu * R / T 单位为个/s     500 * 1/12s = 41.6请求数/sec  1000 * 1/21s = 47.6/sec

|—6.4、吞吐量

指在一次性能测试过程中网络上传输的数据量的总和（单位应该KB）,也可以这样说在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中，吞吐量是重点关注的指标，它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值；

并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：90%用户的平均响应时间，错误率，吞吐量/吞吐量，CPU，内存，磁盘IO,网络的占用情况，还有服务器的配置。

吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

通常情况下，吞吐率用“字节数/秒”来衡量，当然，也可以用“请求数/秒”和“页面数/秒”来衡量；

吞吐量/率和负载之间的关系：

①上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比；

②平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动；

③下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比；

总结：吞吐量/率干不过负载！！！

|—6.5、内存泄漏（memory leak）

是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。

|—6.6、内存溢出（out of memory）：OOM

指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出，简单来说就是自己所需要使用的空间比我们拥有的内存大内存不够使用所造成的内存溢出。

|—6.7、内存溢出原因

1.内存中【加载的数据量过于庞大】，如一次从数据库取出过多数据；

2.集合类中【有对对象的引用，使用完后未清空】，使得JVM不能回收；

3.代码中存在死循环或循环产生过多重复的对象实体；

4.使用的第三方软件中的BUG；

5.启动参数内存值设定的过小

|—6.8、内存溢出的解决方案：

第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)

第二步，检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。

第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。

|—6.9、重点排查以下几点：

2.1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

2.检查代码中是否有死循环或递归调用。

3.检查是否有大循环重复产生新对象实体。

4.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

5.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

第四步，使用内存查看工具动态查看内存使用情况

|—7、性能测试流程

一、准备工作

1、首先要保证系统基础功能验证通过

性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

2、然后就是选择好性能测试工具

综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点：

①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；

②工具运行在Windows平台上；

③支持对webserver、前端、数据库的性能计数器进行监控；

3、然后就是对预先的业务场景分析

为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。

二、测试计划

测试计划阶段最重要的是分析用户场景，确定系统性能目标。

1、性能测试领域分析（也就是确定测试范围，是需要做哪方面的性能测试，并发测试，压力测试，疲劳测试，负载测试）

根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致

系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。

2、用户场景剖析和业务建模

根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。

3、确定性能目标（也就是确定各个用户场景的性能指标）

前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定

最终我们需要达到的响应时间和系统资源使用率等目标；比如：

①登录请求到登录成功的页面响应时间不能超过2秒；

②报表审核提交的页面响应时间不能超过5秒；

③文件的上传、下载页面响应时间不超过8秒；

④服务器的CPU平均使用率小于70%，内存使用率小于75%；

⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；

4、制定测试计划的实施时间

预设本次性能测试各子模块的起止时间，产出，参与人员等等。

三、测试脚本设计与开发

性能测试中，测试脚本设计与开发占据了很大的时间比重。

1、测试环境设计

本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，

在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。

这里所说的配置大概是如下几类：

①数据库服务器

②应用服务器

③负载模拟器

④软件运行环境，平台

测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的

测试数据来使得测试环境的数据保持一致性等等。

可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据，保持一致性。

2、测试场景设计

通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量，操作次数，确定测试指标，以及性能监控等。

3、测试用例设计

确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例大概内容如下：

用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）

用例条件：用户已登录、具有对应权限等。。。

操作步骤：

①进入对应页面。。。。。。

②查询相关数据。。。。。。

③勾选导出数据。。。。。。

④修改上传数据。。。。。。

PS：这里的操作步骤只是个例子，具体以系统业务场景描述；

4、脚本和辅助工具的开发及使用

按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查点等等，最后的结果使得测试脚本可用，能达到测试要求即可；

PS：个人而言，建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！

四、测试执行与管理

在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。

1、建立测试环境

按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。

2、执行测试脚本

这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。

3、测试结果记录

根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或

第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

五、测试分析

1、测试环境的系统性能分析

根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，

进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

2、硬件设备对系统性能表现的影响分析

由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。

3、其他影响因素分析

影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析；

至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

4、测试中发现的问题

在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。

|—如何使用nmon工具检测服务器的资源

1、工具获取

下载地址：

http://sourceforge.jp/projects/sfnet_nmon/releases/ 或者直接从这获取，还包含分析工具。可下载比较全的压缩包：

nmon_linux_14i_newer_Linux_versions.tar.gz

官方地址：http://nmon.sourceforge.net/

2、使用

1. 解压并获取以对应平台的nmon工具文件： nmon_linux_14i_newer_Linux_versions.tar.gz

解压后，可以看到各个平台的文件，我们只需要使用适合的即可，一般是nmon_linux_x86_64。

2. 将nmon工具文件上传至服务器的相应目录并增加可执行权限

a.      上传成功后：

b.      增加可执行权限：

chmod 755 nmon_x86_64_centos6

3.使用nmon工具的实时监控功能

 输入 ./ nmon_x86_64_centos6

3、数据采集

为了实时监控系统在一段时间内的使用情况并将结果记录下来，我们可以通过运行以下命令实现：

$./nmon_x86_64_centos6 -ft  -m /nmon/log -s 1 -c 20

-f：按标准格式输出文件：<hostname>_YYYYMMDD_HHMM.nmon；

-t：输出中包括占用率较高的进程；

-m 切换到路径去保存日志文件

-s 30：每30秒进行一次数据采集

-c 10：一共采集10次

-c 取出多少个抽样数量，这里为120，即监控=120*(30/60/60)=1小时

    根据小时计算这个数字的公式为：c=h*3600/s，比如要监控10小时，每隔30秒采样一次，则c=10*3600/30=1200

输入命令回车后，将自动在当前目录生成一个hostname_timeSeries.nmon的文件，如果hostname为svcpreapp01，生成的文件为：svcpreapp01_151221_1738.nmon，如下：

./nmon_x86_64_centos6 -ft -s 1 -c 10 &

4、生成报告(生成图形化结果)

该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成——即监控1小时，这些操作均自动完成，无需手工干 预，测试人员可以继续完成其他操作。如果想停止该监控，需要通过“#ps –ef|grep nmon”查询进程号，然后杀掉该进程以停止监控。

通过后台监控和定期监控，我们可以得到扩展名为nmon的监控文件，这些文件记录着系统资源的数据，需要配合分析工具（nmon analyser）进行解读。

　　1)   使用FTP工具从服务器上取下生成结果文件/nmon/log/sjfx212_120318_1723.nmon到本机。

　　2)   打开nmon_analyser.zip 包下的nmon analyser v33g.xls 文件，点击Analyse nomn data按钮，选择之前get下来的sjfx212_120318_1723.nmon文件。

5，数据分析

借助nmon analyser可以把nmon采集的数据生成直观的Excel表，nmon analyser可以在IBM的官网下载，https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power+Systems/page/nmon_analyser

在windows上下载后解压，有word和exce两个文档，Word是说明文档，包括更新日志，详细参数等，其中的Excel就是nmon analyser工具了。

Nmon 是一个分析aix和linux性能的免费工具（其主要是ibm为自己的aix操作系统开发的，但是也可以应用在linux操作系统上），而nmon_analyser是nmon的一个工具可以把nmon生成的报告转化成excel报表的形式供我们查看。下面先让看下nmon_analyser生成的报表。

|—1、安装JMeter插

新的版本提供了插件管理器，但是需要自行下载安装。

下载路径：  https://jmeter-plugins.org/downloads/all/

放在lib/ext目录下，然后重启Jmeter，会在菜单-选项下多一个 Plugins Manager菜单，打开即可对插件进行安装、升级。

|—2、Jmeter 插件安装

打开 Plugins Manager 菜单，在可获得的插件列表中选择自己需要的插件进行安装。

常用的插件：

• 支持Base64加解密等多个函数的插件 Custom JMeter Functions

• 用于服务器性能监视的 PerfMon Metrics Collector

• 用于建立压力变化模型的 Stepping Thread Group

• 用于Json解析的 JSON Path Extractor

• 用于展示响应时间曲线的 Response Times Over Time

• 用于展示TPS曲线的 Transactions per Second

|—1、打开插件管理器Plugins Manager

可以看到：

• Installed Plugins： 已经安装的插件

• Avaliable Plugins： 可以下载的其他插件

• Upgrades：一些插件的更新

|—2、比如我们要用自定义线程组这个插件，它不是默认安装的，那就可以进入Avaliable Plugins 来下载安装

搜索thread，选中 Custom Thread Groups,点击 Apply Changes and Restart JMeter

3、重启后就可以添加自定义线程组了

|—3、安装自定义线程组

|—1、自定义线程组设计测试场景

JMeter中我们使用线程组来控制测试场景，原线程组无法设计复杂测试场景，所以要用到JMeter插件提

供的线程组元件Ultimate Thread Group 和 Stepping Thread Group。

|—2、插件安装：

JMeter插件的安装参考：https://blog.csdn.net/galen2016/article/details/92806212

什么是实际的性能测试？？？

1）思考时间：用户在做不同操作之间有时间停顿，或者延迟，思考时间就是模拟用户的操作过程中的停顿的间。

2）步伐，速度：主要包括，大量用户进来的时间和退出时间，控制迭代之间的时间，例如，现场用户20个，设置5秒内全部进入，就是这样的情况。

3）压力测试时间：假如需要500个人同时测试30分钟，这里持续30分钟就是压测时间。

|—3、Ultimate Thread Group

一、简单场景

100个线程，在10秒内加载完，然后持续运行600秒，最后在10秒内结束所有线程，如下图：

参数说明：

• Start Threads Count：开始线程数量

• Initial Delay，sec：延时启动当前行的线程，单位:秒

• Startup Time，sec：线程加载多长时间，单位:秒

• Hold Load For，sec：当前行线程达到峰值后的稳定加载时间，单位:秒

• Shutdown Time：线程在多长时间内停止下来，单位:秒

二、浪涌场景

说明：

第一次从0秒开始，在10秒内启动100个线程，然后持续运行600秒，再在10秒内停止这100个线程

第二次从第620秒开始，在10秒内启动100个线程，然后持续运行600秒，再在10秒内停止这100个线程

第三次第四次 依次类推，只需改动Initial Delay的值，本次Initial Delay的值=等于上一次的（Initial Delay+Startup Time+Hold Load For + Shutdown Time）

三、持续加压场景

说明：

这是一个负载不断增大的场景，有3条线程任务作业，每一个持续时间是600秒，100个线程运行600秒后再加100个，共300个线程。然后从第1810秒开始，没10秒停止100个线程。整个场景共运行1840秒

注意：Hold Load For的值要从最后一个任务往前推算

|—4、Stepping Thread Group

下图是100个线程按阶梯状递增运行，每5秒内加载20个线程直到100，每个阶梯是600秒，最后一个阶梯是1000秒，即并发100个线程时，运行1000秒。最后每秒停止10个线程。

这是一个典型的负载测试场景，持续增加负载，检验服务器在不同负载下的性能。

参数说明：

• This group will start：加载多少线程

• First，wait for：等待多长时间开始加载线程

• Then start：初次加载多少个线程

• Next，add：下一次加载多少个线程

• Threads every：当前运行多长时间后再次加载线程

• Using ramp_up：加载线程时间

• Then hold load for：线程全部加载完成后运行多长时间

• Finally，stop /threads every：多长时间停止多少个线程

|—性能分析

排除法

1，响应是太长  5s

1，中间件问题  apache中间件

          添加中间件的线程数

               linux  查看当前http线程数量

               ps -ef|grep httpd|wc -l

               ps -ef 查看进程  grep httpd 过滤进程 httpd

               wc -l  统计数量

               http.conf文件中 修改 最大连接数           

               /etc/httpd/conf/httpd.conf

2、后台代码

     a. 代码架构合不合理

     b. 代码算法是否存在优化的空间

3、数据库问题

     a.查看数据库的最大连接数

      mysql -u root -p123456

      查询最大连接数据：show VARIABLES like '%max_connect%'

      最多  支持3000-4000

      set GLOBAL MAX_CONNECTIONS=1000  修改连接数

     b.查看sql运行时间

      show full PROCESSLIST 展示所有sql运行的时间

      如果 运行时间过长，进行sql语句优化    

      1，进行sql优化

      2，建立索引文件（增加查询速度）    

    c.索引缓存大小

       show VARIABLES like 'key_buffer_size%'  查看缓存空间大小

       key_reads 从磁盘读取数据

       Key_read_requests 总的数据读取

       命中率：

       命中率：

       命中率计算=key_reads/Key_read_requests*100=1.7%              

       命中率计算=key_reads/Key_read_requests*100%=1.7%

       当命中率 低于0.1% 算ok 高于0.1% 提高缓存空间大小

       当命中率小于0.01% 适当减少一些缓存空间大小

     d，sleep过多

     e，临时表空间    

 4、 排除网络问题                 #抓包数据

      提升网络带宽  200M  看响应时间  会不会大幅度缩短

 5，提升服务器硬件设备

      cpu，内存，磁盘

|—分布式压测

一台主控机，多台客户机

1、在主控机上编写性能测试脚本

2、修改主控机的配置文件jemeter.properties文件，将所有的客户机的IP地址及端口设置好

3、在主控机的Jmeter页面启动客户机 

​      运行->远程启动(指定启动哪一台）

​      运行->远程启动所有

备注说明：如果客户机不够，也可以将主控机用来当成客户机向服务器发请求，这里需要在jemeter.properties配置文件中把主控机的ip地址及端口加入，并启动主控机的jmeter-server.bat文件即可。

所有客户机的数据全部会自动发送给主控机，并进行分析。