(四)软件性能测试

1. 性能测试包含的方法有哪些（至少列举5种）？

  正确回答通过率：69.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

性能测试大致分为以下六类

1、验收性能测试：
通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
目的：验收系统性能是否满足需求。
方法：按照性能需求设置对应的用户并发数，观察各项指标是否满足需求。
2、负载测试：
有时又叫可置性测试。在被测系统上不断增加压力，直到性能指标超过预定指标或者某种资源使用已经达到饱和状态。
目的：找到系统处理能力的极限。
方法：不断增加虚拟用户来不断给系统增加压力，直到系统中部分资源达到饱和。
3、压力测试：
测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理会话的能力，以及系统是否回出现错误。
目的：测试系统在一定饱和状态时，系统处理业务的能力。
方法：不断增加虚拟用户数来不断给系统增加压力，直到系统中部分资源达到饱和，持续运行一段时间，看系统是否会出错。
4、配置测试：
通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。一般用于性能调优。
目的：通过调整环境了解不同因素对系统性能的影响情况，从而找到调优的方法。
方法：通过调整系统软/硬件环境，使系统在不同环境下运行进行性测试。
5、并发测试：
通过模拟用户的并发访问，测试多用户访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
目的：当多用户并发访问时，系统是否存在一些可能的并发问题。
方法：模拟多用户同时并发操作。
6、可靠性测试：
又叫稳定性测试，当系统在一定业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性。
目的：测试系统在一定业务压力下，系统可持续运行的时间。
方法：在一定的业务压力环境下持续运行。
性能测试是测试行业中颇具技术含量的工作，不仅要求工程师对系统进行一系列复杂的需求分析，制定完善的测试计划，设计出贴近实际用户使用场景的测试用例，还要把握系统性能变化趋势，给出专业的优化建议，帮助开发解决性能问题。
性能测试属于测试的高级技术(看图)，是当前企业非常需要的一门测试技术。学习中上等的优秀学员如果掌握了性能测试，在就业市场上就会更有竞争力。

2. 详细描述性能测试的步骤？

  正确回答通过率：50.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

性能测试的步骤流程梳理：

1. 确定性能测试的目标和需求：明确性能测试的目的、测试范围、测试类型、测试指标和测试环境等。
2. 制定性能测试计划：确定测试的时间、资源、测试策略、测试场景、测试数据等。
3. 设计性能测试用例：根据性能测试目标和需求，设计测试用例，包括负载测试用例、压力测试用例、稳定性测试用例等。
4. 配置测试环境和编写性能测试脚本：根据测试需求，配置测试环境，包括硬件、软件、网络等。
5. 执行性能测试：按照测试计划和测试用例执行性能测试，收集测试数据，包括响应时间、吞吐量、并发用户数、CPU利用率、内存利用率等。
6. 分析测试结果：根据测试数据和性能指标，分析系统的性能瓶颈和优化建议，进一步优化系统性能。
7. 编写性能测试报告：总结性能测试结果，并编写性能测试报告，包括测试目的、测试环境、测试过程、测试数据、测试结论和优化建议等。

3. 简述整体来说性能测试什么时候执行？

  正确回答通过率：80.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

性能测试执行时间点：

1：性能测试应该在开发和测试阶段之后，产品上线之前进行。在产品上线之前进行性能测试可以确保产品在正式上线之前能够承受预期的负载和流量，从而避免因为性能问题导致的系统崩溃或用户体验不佳的情况。
2：一般来说，性能测试应该在产品开发稳定且功能基本完成之后进行。在测试阶段，测试人员可以进行基本的性能测试，如单元测试、集成测试等，以确保各个模块的性能表现正常。在产品开发完成之后，可以进行完整的性能测试，包括负载测试、压力测试、稳定性测试等，以全面地评估产品的性能表现和稳定性，并发现和解决潜在的性能问题。
3：需要注意的是，在进行性能测试之前，必须先制定详细的测试计划和测试方案，并确定测试目标和测试指标，以确保性能测试的有效性和可靠性。同时，测试过程中也需要按照测试计划和测试方案进行测试，并记录测试结果和问题，以便后续的分析和优化。

4. 性能测试通常需要监控的指标包括哪些？

  正确回答通过率：36.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

性能测试通常需要监控的指标包括：
1.服务器Linux（包括CPU、Memory、Load、I/O）。
2.数据库：1.Mysql 2.Oracle（缓存命中、索引、单条SQL性能、数据库[/url]线程数、数据池连接数）。
3.中间件：1.Jboss 2. Apache（包括线程数、连接数、日志）。
4.网络： 吞吐量、吞吐率。
5.应用： jvm内存、日志、Full GC频率。
6.监控工具（LoadRunner[/url]）：用户执行情况、场景状态、事务响应时间、TPS等。
7.测试机资源：CPU、Memory、网络、磁盘空间。

5. 解释什么是性能测试？如何进行性能测试？

  正确回答通过率：53.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

系统在一定的压力情况下，查看cpu，内存，磁盘，网络带宽，TPS、响应时间、并发用户数、等各项指标，通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求，就是在特定的运行条件下验证系统的能力状况
1、性能需求分析：明确到底要不要做性能测试，明确被测系统特点、基本业务、关键业务、用户行为，性却性能测试范围，明确性能测试目标及性能指标，性能测试策略。
2、进行测试用例的设计、测试脚本开发与调试、测试环境和测试数据的准备。
3、利用jmeter工具进行性能测试。
4、得出测试数据，进行系统优化，完成测试报告。如果利用jmeter测试工具，利用聚合报告可以看出它的性能，根据性能测试数据与测试性能指标进行比对，达到性能指标说明性能良好。

6. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程

 正确回答通过率：41.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况
　　容量测试：确定系统可处理同时在线的最大用户数
　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），
　　Web服务器指标指标：
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
　　* Successful Rounds：成功的请求；
　　* Failed Rounds ：失败的请求；
　　* Successful Hits ：成功的点击次数；
　　* Failed Hits ：失败的点击次数；
　　* Hits Per Second ：每秒点击次数；
　　* Successful Hits Per Second ：每秒成功的点击次数；
　　* Failed Hits Per Second ：每秒失败的点击次数；
　　* Attempted Connections ：尝试链接数；

7. 压力测试工具能否安装在被测的WEB服务器上进行本地的压力测试?

  正确回答通过率：73.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

一般要求是发压和被压机器分离，便于分析压测结果，最好压测和被压的机器放置在同一机房，降低网络及带宽带来的数据波动和因此导致的瓶颈。
这里无论发压和被压，都是会占用资源。当出现系统瓶颈时，如果两个在同一个机器，对你的分析会造成很大的影响。
如果你的上层请求是同内网下的同idc的调用方法，那么你可以选择同idc的机器进行发压参考。
当然，如果你的预期QPS很低，完全不会达到机器瓶颈，只是验证一些内存泄漏等简单并发问题

8. 如何云平台的性能测试？

 正确回答通过率：93.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

云平台的性能测试和一般的性能测试也是差不多的，云平台的性能并发容量比较大，用户数多一点。
1.首先分析性能测试点如:发生频率非常高的，关键程度非常高的资源占用非常严重的等;
2.性能指标如：首页打开速度，支持最大在线用户，系统支持的并发用户数等;
3.工具的选择：JMeter，Loadrunner等。

9. 性能测试场景设计要考虑哪些因素?

  正确回答通过率：41.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

1、在软件测试测试环境的系统性能分析 根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据， 进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

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

3、其他影响因素分析 影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据2\5\8原则对其进行分析； 至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

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

10. 服务端性能监控指标及命令？

  正确回答通过率：37.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

一、性能监控指标及命令：

1. cpu：服务器的核数直接影响cpu即运算(处理事务)能力
   命令：top
   us（user）：用户态CPU使用时间占比
   sy（system）：内核态CPU使用时间占比
   ni（nice）：低优先级用户态使用时间占比
   id（idle）：空闲的CPU时间比例，值越大，CPU空闲时间比例越高，利用率越低
   wa（iowait）：IO等待状态的CPU时间比例

2. 一般情况下，如果%us+%sy<=70%，我们可以认为系统的运行状态良好。

3. iowait% 表示CPU等待IO时间占整个CPU周期的百分比，如果iowait值超过50%，或者明显大于%system、%user以及%idle，表示IO可能存在问题。

4. 内存：
   命令：top、free –h
   total = used + free
   系统已用内存（used）包含buff/cache

5. 负载：负载即为计算机需要处理的事务的堆积情况，负载上去后理论上cpu占用应该很大(处于最大工作状态)
   命令：top、uptime

三个数值分别表示1分钟、5分钟、15分钟内的平均负载情况
这里的平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，可以简单的理解为平均负载就是系统平均活跃进程数。

4. IO ：
   命令：iostat –x –k 2 3 //每隔2S输出磁盘IO的使用情况，共采样3次

注：占用IO过高，可以做如下考虑：

1）首先考虑写日志内容过多（或者访问量较大）
日志打印的内容是否合理( 前端应用服务器，要避免程序频繁打本地日志、或者异常日志)
日志级别是否合理
考虑异步写日志（一般可以解决CPU锯齿波动），为减少磁 盘IO操作，将日志写如内存分区；但日志量太大，很容易将内存 写满，再考虑将日志进行压缩。
2）磁盘满（压测过程中现象：TPS降低，响应时间增加）

找到导致磁盘满的大文件，合理的删除，最好有定期清理脚本，可以定期清理
对磁盘空间进行扩大磁盘容量
不好清理的，在主硬盘上进行读写操作，基础数据定时移动 到挂载硬盘上。
3）数据库连接数超限制，导致sleep比较多，sleep任务太多的处理：

程序里每次连接数据库后，记得关闭数据库。
或者，在mysql配置文件中，设置mysql超时时间wait_timout, 默认是八小时，设置低一点
4）数据库IO过高，查询量大，可以进行读写分离（增加读库）或者分库操作，减小磁盘压力，调优一些buffer参数以降低IO写的频率
5）磁盘IO过高是由于读写文件导致的: 可以利用raid来减轻压力
6）磁盘本身性能不足: 考虑更换新磁盘（性能强劲的）

5. 磁盘：磁盘占用过高时也会影响性能
   命令1: fdisk –l //查看硬盘及分区情况
   命令2：df –h //查看文件系统的磁盘空间使用情况

6. 网络：网络分为进和出两个即接收请求和发出响应，网络慢直接造成响应时间过长
   网络带宽也是性能测试时要考虑的因素，如果并发量上不去很有可能就是网络带宽的原因。

7. 接口RT标准：一般为400ms以内，实际按业务要求
   二、测试，结果分析

8. 不断增加并发的线程 -得到以下数据 ：
   a. 并发线程数-RT曲线；
   b. 并发线程数-QPS曲线；
   查看a曲线的RT允许范围内的最大线程数：x
   再查看b曲线在最大线程数x下的QPS，该QPS为此服务器配置下的最大QPS

9. 性能调优：
   查看在最大QPS时的cpu、内存负载情况，会出现不同的场景，根据不同场景进行性能瓶颈分析：
   a. cpu比较高，负载也比较高；
   b. 内存过高，cpu上不去；
   c. IO过高
   d. …

三、性能指标
1、硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈。
2、应用软件上的性能瓶颈：
一般指的是服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等
3、应用程序上的性能瓶颈：
一般指的是开发人员，开发出来的应用程序（如sql语句、数据库设计、业务逻辑、算法等）。
4、操作系统上的性能瓶颈：
一般指的是Windows、linux等操作系统，如出现物理内存不足时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率大大降低，从而导致行为的响应时间大大增加，可以认为在操作系统上出现了性能瓶颈）。

5、网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。

11. 介绍下你在工作中使用过的监控和分析工具，各自有什么特点？

 正确回答通过率：54.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

监控工具我常用的是zabbix/Prometheus/grafana/skywalking，分别用他们来查看XXX指标；
分析工具我常用的是arthas，jvm自带的命令分析工具，分别用他们来进行XXX分析；
我还了解和自己研究过XXX工具，发现它的特点很适合XXX类型的问题分析和排查；

12. 解释什么是全链路压测？

  正确回答通过率：53.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

全链路压测的技术难点有：
1、海量并发请求的发起
2、全链路压测流量的隔离
3、实际业务承载能力的模拟
4、压测后数据的清理

一、海量并发请求的发起
工具的选择：
1、由于需要海量的并发，loadrunner是根据并发用户来收费的所以pass掉
2、分布式的jemeter http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html 分布式jemeter详细介绍
分布式的jemeter也会存在各种问题：
1、虽然采用的分布式的测试方案，也会存在并发数量的限制，这是由于jemeter master节点会由于越来越多的节点成为瓶颈
解决：为了解决这个难题，很多公司并不会直接采用分布式JMeter架构来完成海量并发，而是会使用Jenkins Job单独调用JMeter节点来控制和发起测试压力。这样就避免了Master节点引发的瓶颈问题。而且，由于各个JMeter是完全独立的，所以只要Jenkins Job足够多，并且网络带宽不会成为瓶颈的情况下，就能发起足够大的并发。
2、测试脚本、测试数据、测试结果在分布式框架中分发的难题
解决：如果采用分布式jemeter的方案 测试脚本需要master下发给slave 测试数据需要自己上传到slave节点 测试结果需要slave回传给master，所以需要建立一套以jemeter为框架的压测平台，通过框架来处理以上问题。
3、流量发起的地域要求 压力来自全国的各个地方
解决：在全国重点城市搭建jemeter slave节点

二、全链路压测流量的隔离
因为全链路压测是在真实的测试环境中执行的，测试数据一定要与真实的数据隔离，以免对生产环境的数据产生污染，有两种方法：
1、增加流量标记，不将压测试数据统计到报表里
2、测试完成后，对测试数据进行清理

三、真实模拟线上业务
模拟线上业务包括两个方面 1、真实的流量数量级 2、真实的业务场景解决：录制真实的业务流量 清洗后回放

四、压测后数据的清理
由于全链路压测是在真实的生产环境中进行的，那么完成的所有交易以及相关的支付都是真实有效的，所以我们就需要在测试结束后，将这些交易撤销。

因为，我们已经对这些交易的流量和数据进行了特定标记，所以我们可以比较方便地筛选出需要撤销的交易，然后通过自动化脚本的方式来完成批量的数据清理工作

五、性能
除了上面的四大问题以外，全链路压测还需要考虑测试执行过程中的性能监控、高强度压测负载下的测试熔断机制、全链路压测执行期间对原有系统正常负载的影响、全链路压测数据对外的不可见等等。

13. JVM堆内存的结构，YGC,FGC的原理是什么？

 正确回答通过率：54.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

1 JVM堆内存主要分为新生代(Young Gen)、老年代(Tenured Gen)、持久代(Perm Gen)；
2 新生代划分为伊甸区(Eden)、幸存区from区(Servivor from)、幸存区to区(To Servivor)；
3 老年代的特点是占用内存大，垃圾回收操作频率低；
持久代主要存放类定义、字节码和常量等很少会变更的信息；

14. 详细阐述前后端性能测试的方法有哪些？

  正确回答通过率：40.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

第一，后端性能测试
其实，你平时听到的性能测试，大多数情况下指的是后端性能测试，也就是服务器端性能测试。
后端性能测试，是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验 证各项指标是否符合预期的性能需求的测试手段。
这里的性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应该包括各类资源的使用率，比 如系统级别的CPU占用率、内存使用率、磁盘I/O和网络I/O等，再比如应用级别以及JVM级别的各类资 源使用率指标等。
由于需要模拟的并发用户数，通常在“几百”到“几百万”的数量级，所以你选择的性能测试工具，一定不 是基于GUI的，而是要采用基于协议的模拟方式，也就是去模拟用户在GUI操作的过程中实际向后端服 务发起的请求。
只有这样才能模拟很高的并发用户数，尽可能地模拟出真实的使用场景，这也是现在所有后端性能测试 工具所采用的方法。
根据应用领域的不同，后端性能测试的场景设计主要包括以下两种方式：
基于性能需求目标的测试验证； 探索系统的容量，并验证系统容量的可扩展性
随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用 户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系 统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。

第二，前端性能测试
前端性能测试并没有一个严格的定义和标准。
通常来讲，前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情 况、资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优 化，最终达到优化终端用户在浏览器端使用体验的目的。

目前，业界普遍采用的前端测试方法，是雅虎（Yahoo）前端团队总结的7大类35条前端优化规则，你 可以通过雅虎网站查看这些规则，以及对各规则的详细解读。
我在这里列出了其中几个最典型也是最重要的规则，来帮助你理解前端性能测试优化的关注范围。
减少http请求次数：http请求数量越多，执行过程耗时就越长，所以可以采用合并多个图片到一个 图片文件的方法来减少http请求次数，也可以采用将多个脚本文件合并成单一文件的方式减少http请 求次数； 减少DNS查询次数：DNS的作用是将URL转化为实际服务器主机IP地址，实现原理是分级查找，查 找过程需要花费20~100ms的时间，所以一方面我们要加快单次查找的时间，另一方面也要减少一个 页面中资源使用了多个不同域的情况； 避免页面跳转：页面跳转相当于又打开一个新的页面，耗费的时间就会比较长，所以要尽量避免使 用页面跳转； 使用内容分发网络（CDN）：使用CDN相当于对静态内容做了缓存，并把缓存内容放在网络供应商 （ISP）的机房，用户根据就近原则到ISP机房获取这些被缓存了的静态资源，因此可以大幅提高性 能； Gzip压缩传输文件：压缩可以帮助减小传输文件的大小，进而可以从网络传输时间的层面来减少响 应时间；

第三，代码级性能测试
代码级性能测试，是指在单元测试阶段就对代码的时间性能和空间性能进行必要的测试和评估，以防止 底层代码的效率问题在项目后期才被发现的尴尬。
如果你从事过性能测试相关的工作，一定遇到过这样的场景：系统级别的性能测试发现一个操作的响应 时间很长，然后你要花费很多时间去逐级排查，最后却发现罪魁祸首是代码中某个实现低效的底层算 法。这种自上而下的逐级排查定位的方法，效率通常都很低，代价也很高。
所以，我们就需要在项目早期，对一些关键算法进行代码级别的性能测试，以防止此类在代码层面就可 以被发现的性能问题，遗留到最后的系统性能测试阶段才被发现。
但是，从实际执行的层面来讲，代码级性能测试并不存在严格意义上的测试工具，通常的做法是：改造 现有的单元测试框架。
最常使用的改造方法是：

1. 将原本只会执行一次的单元测试用例连续执行n次，这个n的取值范围通常是2000~5000；
2. 统计执行n次的平均时间。如果这个平均时间比较长（也就是单次函数调用时间比较长）的话，比 如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑一定需要优化。
   这里之所以采用执行n次的方式，是因为函数执行时间往往是毫秒级的，单次执行的误差会比较大，所 以采用多次执行取平均值的做法。

第四，压力测试
压力测试，通常指的是后端压力测试，一般采用后端性能测试的方法，不断对系统施加压力，并验证系 统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈 点。所以，压力测试往往被用于系统容量规划的测试。
还有些情况，在执行压力测试时，我们还会故意在临界饱和状态的基础上继续施加压力，直至系统完全 瘫痪，观察这个期间系统的行为；然后，逐渐减小压力，观察瘫痪的系统是否可以自愈。

第五，配置测试
配置测试，主要用于观察系统在不同配置下的性能表现，通常使用后端性能测试的方法：

1. 通过性能基准测试（Performance Benchmark）建立性能基线（Performance Baseline）；
2. 在此基础上，调整配置；
3. 基于同样的性能基准测试，观察不同配置条件下系统性能的差异，根本目的是要找到特定压力模式 下的最佳配置。
   这里需要注意的是，“配置”是一个广义配置的概念，包含了以下多个层面的配置：
   宿主操作系统的配置； 应用服务器的配置； 数据库的配置； JVM的配置； 网络环境的配置； …

第六，并发测试
并发测试，指的是在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨 在发现诸如资源竞争、资源死锁之类的问题。
谈到并发测试，我就不得不和你说说“集合点并发”的概念了，它源于HP的LoadRunner，目前已经被广 泛使用了。那，到底什么是“集合点并发”呢？
假设我们希望后端调用的并发数是100，如果直接设定100个并发用户是无法达到这个目标的，因为 这100个并发用户会各自执行各自的操作，你无法控制某一个确定的时间点上后端服务的并发数量。
为了达到准确控制后端服务并发数的目的，我们需要让某些并发用户到达该集合点时，先处于等待状 态，直到参与该集合的全部并发用户都到达时，再一起向后端服务发起请求。简单地说，就是先到的并 发用户要等着，等所有并发用户都到了以后，再集中向后端服务发起请求。
比如，当要求的集合点并发数是100时，那么前99个到达的用户都会等在那里，直到第100个用户到了， 才集中向后端服务发起请求。当然，实际达到服务器的并发请求数，还会因为网络延迟等原因小 于100。
所以，在实际项目中，我建议在要求的并发数上进行适当放大，比如要求的并发数是100，那我们集合 点并发数可以设置为120。

第七，可靠性测试
可靠性测试，是验证系统在常规负载模式下长期运行的稳定性。
虽然可靠性测试在不同公司的叫法不同，但其本质就是通过长时间模拟真实的系统负载来发现系统潜在 的内存泄漏、链接池回收等问题。
由于真实环境下的实际负载，会有高峰和低谷的交替变化（比如，对于企业级应用，白天通常是高峰时 段，而晚上则是低峰时段），所以为了尽可能地模拟出真实的负载情况，我们会每12小时模拟一个高峰 负载，两个高峰负载中间会模拟一个低峰负载，依次循环3-7天，形成一个类似于“波浪形”的系统测试 负载曲线。14

15. 性能测试里如何确定系统最大负载？

 正确回答通过率：43.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

通过负载测试，不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数就是系统能承载的最大用户数。

16. 性能测试里面如何确定并发用户数？

  正确回答通过率：53.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

一、首先涉及到并发用户数可以从以下几个方面去做数据判断。
1.系统用户数
2.在线用户数
3.并发用户数
二、三者之间的关系
1.在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。
2.在线用户数和并发用户数又存在着关系。即：平均并发用户数为:c=NL/T L为在线时长，T为考核时长。例如:考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n2/8 n为登录系统的用户数，L为登录的时常。例如:一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为:c=4002/8

17. 软件性能测试的应用领域有哪些（至少列出三种）？

 正确回答通过率：75.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

l 能力验证
l 能力规划
l 性能调优
l 缺陷发现

18. 请描述SEI软件性能测试过程？

 正确回答通过率：78.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

SEI 负载测试计划过程将目标、用户、用例、生产环境、测试环境和测试场景6个区域作为负载测试计划需要重点关注和考虑的内容，重点关注以下几个方面的内容：生产环境和测试环境的不同,用户分析,用例

19. 请描述RBI软件性能测试过程？

 正确回答通过率：90.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

RBI方法是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法，该方法基于以下一些事务：

1. 80%的系统性能瓶颈由吞吐量制约。
2. 并发用户数和吞吐量瓶颈之间存在关联。
3. 采用吞吐量测试能够更快速的定位问题。
   RBI方法先访问“小页面”和“简单应用”，从应用服务器、网络等基础层次上去了解系统吞吐量表现；再选择不同场景、设定不同并发数，使吞吐量保持趋势增长，观察系统的性能表现。按照“自上而下”的方式进行分析，首先确定是并发还是吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器、代码本身4个环境确定系统性能具体的瓶颈。

20. 请描述LR性能测试过程？

 正确回答通过率：89.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

1. 计划测试: 测试需求收集、典型场景确定。
2. 测试设计: 测试用例设计。
   3.创建VU脚本: 根据用例创建脚本。
3. 创建测试场景: 测试场景设计和设置，包括监控指标设定。
4. 运行测试场景: 执行测试场景，收集相应数据。
5. 分析结果: 结果分析和报告工作

21. 对于Web系统的响应时间，行业中被广泛认可的用户可以接受的时间是多少秒？

  正确回答通过率：83.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

2/5/10S，不同行业业务也有不同，非绝对。
在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。
在5秒之内给客户响应被用户认为是“比较不错”的用户体验。
在10秒之内给客户响应被用户认为是“糟糕”的用户体验。

22. 请描述什么是系统吞吐量？

 正确回答通过率：73.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

吞吐量（也称为整机包转发率）是指网络、设备、端口或其他设施在单位时间内成功地传送数据的数量（以比特、字节等为测量单位），也就是说吞吐量是指在没有帧丢失的情况下，设备能够接收并转发的最大数据速率。
　　吞吐量是一个极限指标，即网络设备在所有端口满配，并工作在端口的最高线速的情况下的一个指标。如果仍然以前面提到的连接不同城市的高速公路交通系统来比喻的话，一台交换机的吞吐量相当于进出这个系统内所有城市的交通流量之和，也即交换机所有端口的双向（双工）包转发率之和。
　　吞吐量的大小主要由网络设备的内外网口硬件，及程序算法的效率决定，尤其是程序算法，对于像需要进行大量运算的设备来说，算法的低效率会使通信量大打折扣。
设备：
H3C S3600-28P-EI 
公布包转发率：9.6Mpps 
接口：24个10/100Base-TX
以太网端口，4个1000Base-X SFP
千兆以太网端口(就是24个100M＋4个1000M）
计算：0.1488Mpps24+1.488Mpps4=3.5712Mpps+5.952Mpps=9.5232Mpps 
结果9.5232Mpps <公布包转发率：9.6Mpps,满足全端口“线速转发”

23. 请举例说明什么时候广义并发和严格并发？

  正确回答通过率：95.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

广义并发：广义的并发实际上是在一个时间内操作事务的虚拟用户，是存在。
对地铁这个系统而言，每个时间都有新来的人，也有走的人，大家做的事情基本都相同，乘地铁。假定某个时刻地铁大厅中有10000人，检票口候车的有100人，刚刚开走的地铁上乘有2000人，那此时对考察的系统（列车）而言，并发就是2000人，而如果考察的是检票处，则并发为100人，同样，如果考察的系统是地铁大厅，那此时的并发就是10000人。这种并发我们一般称之为“广义并发”。
严格并发：是指大量用户在同一时刻在软件系统上做完全相同的功能操作或相同类型的功能操作。例如双十一的秒杀商品

24. Web系统，用户最关注的性能指标是什么？

 正确回答通过率：71.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

响应时间

25. 响应时间和吞吐量直接的关系是什么？

 正确回答通过率：64.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

吞吐量图显示的是虚拟用户每秒钟从服务器接收到的字节数。当和响应时间比较时，可以发现随着吞吐量的降低，响应时间也降低，同样的，吞吐量的峰值和最大响应时间差不多在同时出现。
平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小

26. 请解释什么是内存泄露，内存泄露的危害有哪些？

 正确回答通过率：37.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 高难

内存泄漏是指对象不再被应用程序使用，但是垃圾回收器却不能回收它们，因为它们正在被引用。
对于长时间运行的程序来说，内存泄漏会使程序占用的内存一直增加，最后就会出现内存耗尽而导致宕机，即使不宕机也会是系统的运行越来越慢，还有就是有些内存有其他资源，比如数据库连接，网络连接等等这些会出现阻塞。

27. 如何设计系统负载策略?标准是什么?

 正确回答通过率：83.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

建议：加压实行减半，标准是系统的性能基线，就是在系统的cpu、内存都不低于75%，响应时间小于3s时测出来的用户数和标准为参考基线。

28. 解释什么是Think Time？你如何改变这个阈值？

 正确回答通过率：74.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

Think Time是一个真实的用户动作之间的等待时间。例如：当一个用户从服务器接收数据时，用户可以在响应前等待几秒钟来检查响应数据。此延迟就是Think Time。更改这个阈值：阈值是一个标准水平，思考时间低于阈值水平时将被忽略，Vugen不会生成思考时间语句。默认值是5秒。我们可以在Vugen录制选项中改变Think Time阈值。

29. 从管理员角度视角，主要关注系统性能的哪些指标？

 正确回答通过率：91.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

①系统的响应时间；
②系统状态的相关信息，如：CPU、内存、应用服务器状态、JVM可用内存、数据库的状态等；
③系统的可扩展性，处理并发的能力；
④系统可能的最大容量，可能的性能瓶颈，通过更换哪些设备或是进行哪些扩展能够提高系统性能；
⑤长时间运行是否足够稳定，是否能够不间断的提供业务服务等；

30. 从开发工程师视角，主要关注系统性能哪些指标？

 正确回答通过率：89.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 初级

（1）系统架构：架构设计是否合理；
（2）数据库设计：数据库设计是否存在问题；
（3）代码：代码是否存在性能方面的问题，系统中是否有不合理的内存使用方式；
（4）设计与代码：系统中是否存在不合理的线程同步方式，系统中是否存在不合理的资源竞争；

31. 请描述压力测试和负载测试的区别？

 正确回答通过率：76.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

压力测试的预期结果就是系统出现问题，我们考察的是系统处理问题的能力。
负载测试是考察软件系统在既定负载下的性能表现。
压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。

32. 请描述什么是系统性能拐点？

 正确回答通过率：83.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

系统性能开始急剧下降的点。

33. 简述在性能测试中遇到哪些性能问题?

  正确回答通过率：31.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

性能测试，是结合被测系统应用架构、业务场景和实现细节、逻辑，对软件响应时间、处理速率、容错能力等进行分析测试，找到系统的性能瓶颈，并确认问题得到解决的过程。
一、硬件
磁盘空间：磁盘空间不足导致系统运行变慢，文件、日志等无法生成存放导致的性能瓶颈；
CPU：CPU的核心功能是解释计算机指令以及处理数据，性能主要体现在其运行程序的速度上。影响运行速度的性能指标包括工作频率、Cache容量、指令系统和逻辑结构等参数；
IO读写速率：即input和output，输入和输出，主要考虑数据处理时的读写速度，页交换等情况；
内存：所有的程序都是运行在内存中的，其作用是用于暂时存放CPU中的运算数据，以及与外部存储器交换的数据，内存不足会限制程序的数据处理速度，因此这也是很重要的一项性能关注指标；

二、网络
带宽：高并发情况下，如果带宽不足，可能会导致网络资源竞争，超时等情况；
网络波动：这里是从网络的稳定性来描述，即性能测试的环境，需要一个稳定的网络环境；
CDN：即内容分发服务，有时候不同的CDN策略也会影响到“用户”感知到的系统性能表现；
延时：延时的值越大，对系统性能表现影响越大（比如格斗类的PVP游戏），且性能测试的结果也存在更大的偏差；
丢包：数据在网络上是以数据包的形式传输的，如果丢包，则可能造成报错或异常的情况；

三、应用
1、JVM
堆内存分配：根据系统硬件条件来进行合理的堆内存分配，一般来说JVM的堆内存分配不要超过系统内存的25%较好；
垃圾回收算法：JAVA的动态垃圾回收机制，是基于不同的几种回收算法来进行的，根据具体的情况，选择合适的垃圾回收策略；
OOM：即内存溢出（out of memory），这个算是性能测试中很常见的一个问题，通常是由于代码问题造成的内存泄漏、GC不够彻底、内存被耗尽引起；

2、代码逻辑
常见的情况有不合理的线程引用和内存分配；

四、配置
版本：在性能测试过程中，一定要确保被测系统的版本和实际生产保持一致，否则由于版本不同带来的些许差异可能会对性能测试带来很大的偏差和影响；
底层配置：涉及到操作系统、服务器等硬件的一些配置方式不合理，带来的性能瓶颈；
参数配置：系统架构设计中，各个不同的参数配置带来的性能瓶颈

五、数据库
索引：索引的存在就像一个标签目录一样，在执行数据库操作时提供更为快速的执行效率，减少磁盘IO操作和执行的数据库系统时间；
锁：为了保证事务的原子性和隔离性，有了锁的存在，但有时候由于某些原因造成的表锁，也是性能瓶颈的一种表现；
表空间：不合理的表空间设计，导致的数据库性能问题；
慢SQL：慢SQL会导致数据库操作时间变长，增加IO读写以及引起一些列的资源竞争等问题，常见的慢SQL原因如下（以MySQL为例）：
数据量：对同一张表来说，1W条数据和1000W条数据，对其进行操作时的性能表现也是不同的，因此在性能测试时对于数据的正确性可用性，以及数据量也是需要重点关注的；

六、中间件
超时：设置合理的请求或响应超时时间，是很有必要的，这点要根据具体的业务场景和系统架构来考虑，具体的超时时间，建议进行配置测试来设定；
线程池：线程池配置太小，很容易被使用完，太大的话又浪费资源，合理的线程池，建议进行配置测试来确定；
缓存策略：缓存的优点是减少请求响应过程中的传输时间，但有时候在高并发情况下，缓存很容易失效而导致缓存穿透，瞬间对服务端带来很大的压力；
最大连接数：关于连接线，之前的博客也介绍过，合理的连接数配置是很重要的，否则连接数太少容易导致队列等待、超时，连接数太多则浪费了系统资源；
通信实现方式：同步（sync）和异步（Async）；
负载均衡策略：现在很多的系统都进行了服务集群，随之而来的就是负载均衡策略的实现，如果负载均衡不够“均衡”，在大数量的冲击下，容易导致某些服务的异常或者挂起；

34. 性能测试如何防止数据污染？

  正确回答通过率：71.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

1、尽量在生产环境不留痕，必须使用非脱敏数据时，需要提前报备，进行操作；
2、必须要进行的操作，需要在测试数据都要打上测试的标识或备注，然后测试完成后，评估是否需要提sql工单清除数据。
3、操作数据库时，是否考虑建立一个视图表（VIEW_TABLE）,本质上视图表可以筛选掉敏感信息（也就是数据脱敏），测试人员对视图表进行操作也是防止测试收据受污染的情况。一般适用于线上跑自动化，或者 是线上做性能压测场景。

35. 怎么根据线下环境评估线上环境的性能？

  正确回答通过率：60.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

1、首先线下必须要有专门的性能测试环境
2、线下环境单台机器配置和线上不能相差很大，可以通过单台的机器性能推算出多台机器性能
3、如果线下机器配置很差，只能测试出程序有无性能问题，这样线下测试出来的数据对线上没有太大的参考意义
4、如果想获取比较准确的线上性能情况，建议最好做线上的性能测试。

36. 性能测试中TPS上不去的几种原因？

 正确回答通过率：65.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
（关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程）
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS
也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
（关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理）
6、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8、压测脚本
还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

37. 解释什么是集合点？设置集合点有什么意义？

 正确回答通过率：71.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

集合点可以设置多个虚拟用户等待到一个点，同时触发一个事务，已达到模拟真实环境中多个用户同时操作，同时产生负载，实现性能测试的最终目的。

38. 服务器的CPU使用率和Load是什么关系?

  正确回答通过率：56.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

1、CPU使用率
一段时间之中，CPU用于执行任务占用的时间与总的时间的比率
2、Load负载
Load average是指上一分钟同时处于就绪状态的平均进程数。在CPU中可以理解为CPU可以并行处理的任务数量，就是CPU个数X核数。如果CPU Load等于CPU个数乘以核数，那么就说CPU正好满负载，再多一点，可能就要出问题了
对于CPU密集型任务 通常是 cpu使用率和load都很高
对于IO密集型任务 通常是cpu使用率不高 但load很高，

39. Linux系统中的buffer和cache都起到什么作用？内存占用有大量的buffer和cache是异常情况吗？

  正确回答通过率：46.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

buffer和cache都是Linux中的缓存机制，cache里一般会缓存一些文件的内容，buffer会缓存一些需要写入磁盘的数据。
Linux会利用空闲的内存做一些缓存，加快文件的访问速度。如果系统可用内存不足时，Linux会释放掉buffer和cache所占用的内存。
所以内存占用中有大量的buffer和cache也是正常现象

40. 性能测试脚本中，定义事务的原则是什么？

 正确回答通过率：73.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

在测试脚本中，事务定义的业务流程越短越好。同时脚本中不要写过多复杂的逻辑，对于一个复杂的场景，可以考虑把脚本拆解成多个简单的脚本

41. 怎么进行性能场景设计？

 正确回答通过率：76.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

通用类场景：
a> 单接口测试场景
b> 混合接口测试场景
c> 高可用性场景（集群情况下）
d> 网络异常场景（如有必要）
e> 稳定性场景
f> 其他业务相关场景

42. 云上部署的应用怎么压测？

 正确回答通过率：65.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

1 在云上申请一台机器当做压力机，与部署应用同区域机房，这样相当于在云上内网压测
2 与局域网压测一样，使用通用工具LR、Jmeter进行压测

43. 请描述什么时候性能平坦区?

 正确回答通过率：75.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

该区域可被用作基线。性能不断加压，没有什么变化

44. 完整的性能测试用例应该包含哪些内容？

  正确回答通过率：66.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

性能测试方案需包含测试测试需求分析、测试资源准备、测试风险、测试执行策略、测试报告输出这几个关键点：
测试需求分析：测试中涉及的测试目的、测试指标、测试对象的分析定义。
测试资源准备：测试中涉及的测试环境、测试工具、测试数据、测试桩、测试人员&周期的分析准备。
测试风险分析：测试中涉及的环境风险、人力风险、技术风险的分析定义。
测试执行策略：测试中涉及的测试类型、测试用例、测试轮次的分析定义。
性能测试报告：测试中涉及的测试结果分析，并输出测试进度报告和测试结论报告的规范定义。

45. 简述怎样分析性能测试结果？

  正确回答通过率：42.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

1. 指标分析
   以Linux+Java架构系统为例, 当得到性能测试结果, 拿到数据之后, 如何分析性能瓶颈在哪里呢?一般指标分析思路如下:

判断业务指标(响应时间, 成功率, TPS)是否满足目标?
若不满足, 则先排除施压机和外围依赖系统是否有瓶颈?
若没有, 则关注网络, DB性能以及连接数是否存在性能问题?
若不存在, 则检查应用系统如下指标是否正常:
4.1. 硬件: 磁盘是否写满, 内存是否够用, CPU利用率以及Load值是否正常
4.2. 软件: JVM内存管理及回收是否合理, 应用程序本身代码是否隐藏性能问题

我们在定位的时候, 可以根据标注中的数字: 1, 2, 3, 4, 5, 6, 7依次进行排查, 先排查施压机是否有瓶颈, 接着看后端依赖系统, DB, 网络等, 最后看被压机本身, 列如响应时间逐渐变慢, 一般来说是外围依赖的系统出现的瓶颈导致整体响应变慢.

1.1. 系统瓶颈分析
服务器负载瓶颈经常表现为, 服务器受到的并发压力比较低的情况下, 服务器的资源利用率比预期要高, 甚至高很多. 导致服务器处理能力严重下降, 最终有可能导致服务器宕机, 实际性能测试工作中, 经常会用到以下三种类型资源指标判定是否存在服务器负载瓶颈: CPU利用率, 内存使用率, Load.
一般CPU使用率应低于50%, 如果过高有可能程序算法消耗太多CPU, 或者某些代码块进行不合理的使用, Load值尽量小于CPU核心数, 其中CPU和Load一般与并发数成正比

内存可以通过两种方式来看:

1. 当vmstat命令输出的si和so值显示为非0值, 则表示剩余可以支配的屋里内存已经严重不足, 需要通过与磁盘交换内容来保持系统稳定; 由于磁盘处理的速度远远小于内存, 此时就会出现严重的性能下降, si和so的值越大, 表示性能瓶颈越严重
2. 用工具监控内存使用情况, 如果出现如下图的增长趋势, (used曲线呈线性增长), 有可能系统内存沾满的情况;

如果出现内存占用一直上升的趋势, 有可能系统一直在创建新的线程, 旧的线程还未销毁, 或者应用申请了堆外内存, 一直没有回收导致内存一直增长

1.2. JVM瓶颈分析
对于Java应用来说, 过高的GC频率也会在很大程度上降低应用的性能, 即使采用了并发收集的策略, GC产生非停顿时间积累起来也是不可忽略的, 特别是出现了cmsGC失败, 导致fullGC的场景
①CMSGC频率过高
当在一段较短的时间区间内, cmsGC值超出预料的大, 那么说明该JAVA应用在处理对象策略上存在一些问题, 即过多过快的创建了长寿命周期的对象. 或者old区大小分配或者回收比例设置的不合理, 导致cms频繁触发, 下面看一张gc监控图(蓝色线代表cmsGC)

由图可以看出cmsGC非常频繁, 后经分析是因为jvm参数-XX: CMSInitiatingOccupancyFraction设置为15, 比例太小导致cms比较频繁, 这样可以扩大cmsgc占old区比例, 降低cms频率注

②FullGC频繁触发
当采用cms并发回收算法, 当cmsgc回收失败时会导致fullgc
由上图可以看得出fullgc的耗时非常长, 在6-7s左右, 这样会严重影响应用的响应时间,经分析是因为cms比例过大, 回收频率较慢导致, 调优方式: 调小cms回收比例, 尽早触发cmsgc, 避免触发fullgc, 调优后回收情况如下
可以看出cmsgc时间缩短了很多, 优化后可以大大提高, 从上面两个例子可以看出cms比例不是绝对的, 需要根据应用的具体情况来看, 比如应用创建的对象存活周期长, 且对象较大, 可以适当提高cms的回收比例

③内存泄漏
分析: 每次cmsgc没有回收干净, old区呈上升趋势, 疑似内存泄漏, 最终有可能导致OOM, 这种情况就需要dump内存进行分析:
找到oom内存dump文件, 具体的文件配置在jvm参数里,
-XX: HeapDumpPath=/home/admin/logs
-XX: ErrorFile=/home/admin/logs/hs_err_pid%p.log

2. 建模分析
   2.1. 理发店模型
   图中展示的是一个标准的软件性能模型, 在图中有三条曲线, 分别表示资源的利用情况, (Utilization, 包括硬件资源和软件资源), 吞吐量(Throughput, 每秒事务数), 以及响应时间(Response Time), 图中横坐标从左到右表示并发用户数不断增长.
   当系统负载等于最佳并发用户数时, 系统的整体效率最高, 没有资源浪费, 用户也不需要等待; 当系统负载处于最佳并发用户数和最大用户并发数之间时, 系统可以继续工作, 但是用户的等待时间延长, 满意度开始降低, 并且如果负载一直持续, 将会导致有些用户无法忍受而放弃, , 而当系统负载大于最大用户并发数时, 将会注定导致某些用户无法忍受超长的响应时间而放弃, 所以我们应该保证最佳并发用户数要大于系统的平均负载

2.2. 压力变化模型

随着单位时间流量的不断增长, 被测系统的压力不断增大, 服务器资源会不断被消耗, TPS值会因为这些因素而发生变化, 而且符合一定规律
a点: 性能期望值
b点: 高于期望, 系统资源处于玲姐点
c点: 高于期望, 拐点
d点: 超过负载, 系统崩溃

2.3. 容量计算模型
以爱吼网性能测试为例:
通过分析运营数据, 可知道当前系统每小时处理的PV数
通过负载测试, 可以知道当前系统每小时的最大处理的PV数
系统每小时PV处理的剩余量 = 系统每小时最大处理的PV数 - 系统每小时处理的PV数
假设爱吼网用户负载基本成线性增长, 现在有系统用户数为70万, 根据运维推广计划, 1年内爱吼网用户将达到1000万, 即增长了14倍, 即:
系统每小时PV处理增加量 = 当前系统每小时处理的PV数 * 14 - 当前系统每小时处理的PV数
系统每天PV处理的增加量 = 系统每小时处理的PV增加量 * 每天系统负载增加率 * 24
所以,在正常负载条件下:
系统可支持正常运行的天数 = 系统每小时PV处理的剩余量 * 24 / 系统每天PV处理的增加量
假设爱吼网后续部署升级天数已知, 提前升级的天数:
系统可支持正常运行的天数 - 部署天数

3. 性能测试报告
   一份好的性能测试报告: 不仅要反馈缺陷问题, 更要对问题进行深入分析, 并提出相应的解决方案, 内容一般包括以下4个方面:
   测试目标
   测试结论
   测试问题&优化建议
   测试结果&分析
   可以根据不同需求对象提供相应有价值的信息, 对测试人员而言, 性能测试需求来自于用户, 开发, 运维的三方面, 用户和开发关注的是与专业业务需求相关的产品指标, 而运维人员关注的是与硬件消耗相关的资源指标

(1)用户角度:
用户关注的是单次业务的相关体验效果, 譬如一次操作的响应快慢, 一次请求是否成功, 一次连接是否失败等, 反应单次业务相关指标包括:
①成功率
②失败率
③响应时间
(2)开发角度:
开发人员更关注的是系统层面的指标
①容量: 系统能够承载的最大用户访问量是多少?
②稳定性: 系统是否支持7*24小时的业务访问
(3)运维角度:
运维人员更关心的是硬件资源系统的消耗情况

46. 系统并发200个用户，服务器返回 http status-code = 500？

 正确回答通过率：89.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

数据库连接没有来得及关闭，就有用户访问上来了，导致数据库崩溃 。这个就是数据库的链接这块开发没有处理好