🌈 赏金任务 - 压测之前需要做什么准备，遇到问题怎么分析？

测试服务 赏金任务
1

赏金任务每周更新，请持续关注哦 :love_letter:

题目

  • 模拟面试场景，面试官提问以下问题，你如何回答。
  • 压测之前需要做什么准备，遇到问题怎么分析？

参与方式

  • 本帖下方回复你的答案即可

赏金

  • 100元京东购物卡

活动时间

  • 2023年3月20日 - 2023年3月26日

本周赏金任务汇总：🌈 赏金任务发布 2023-03-20

本问题参与赏金活动，详情点击 :rainbow: 赏金活动上线啦 丨做赏金任务挑战千元奖金 查看活动介绍

1 个赞
2

准备工作有一下几点：
1.确定测试目标和范围：在开始测试之前，测试人员应该明确测试的目标和范围，以确保测试不会超出预期的范围。
2.确定测试环境：测试人员应该确定测试环境，包括操作系统、数据库、中间件等等。这样可以确保测试结果与实际环境一致。
3.编写测试用例：测试人员应该编写测试用例，以覆盖测试目标和范围内的所有情况。测试用例应该包括正常情况、异常情况和性能测试。
4.执行测试：测试人员应该执行测试，并记录测试结果。如果测试遇到问题，需要及时分析问题原因，并采取相应措施解决问题。
5.报告测试结果：测试人员应该记录测试结果，并向项目经理报告测试结果。测试结果应该清晰、简洁地描述测试结果。
6.修复测试问题：如果测试中发现了问题，测试人员应该及时修复问题，以确保测试结果的准确性。

如果在测试过程中遇到问题，测试人员需要及时分析问题原因，并采取相应措施解决问题。测试人员应该记录问题的详细信息，并将其提交给开发人员进行修复。如果问题无法在测试中修复，测试人员应该将问题提交给更高层次的管理人员进行处理。

3

准备：
1、找产品或者规划确认性能场景和性能指标，确定性能测试范围：长稳测试，摸高测试，压力测试
2、部署性能测试环境：根据组网图、服务规格，网络配置策略部署性能测试环境
3、调试性能脚本：在性能测试环境先调低并发量，将性能脚本调试通过
4、将性能测试环境恢复至性能测试配置，如日志级别恢复等

分析问题：
1、一般通过监控工具，观察cpu、内存、io、网络带宽走势，观察cpu或内存是否占用超过70%，是否有明显波动，io和磁盘占用是否异常，网络带宽是否异常
2、分析测试脚本成功率，确认是否出现大量业务异常----如果出现异常，分析业务日志，确认原因
3、观察业务日志是否出现error或exception，或进程core掉，发现业务core掉，将core文件等相关文件交由开发分析
4、开启内存泄露检测工具，观察是否有内存泄漏
5、最重要的，确保性能压力达到了预期水平（可通过查库等手段，统计性能工具的压力确实加到了业务机）

4

首先我们要做性能预估

面对一个集群 , 性能如何应该怎么预估呢?

没别的办法 , 看经验 , 靠猜？

但是也可以使用一些简单的办法 , 比如

  1. 由小道大 , 逐级测试 → 用一个小的压力做初次预估 , 慢慢逼近性能极限
  2. 参照物法 , 逐渐逼近 → 一组内公司内类似规模的系统 , 进行初次预估
  3. 玄学瞎猜 , 慢慢测试 → 没有任何可以参考的就瞎猜一个吧 , 然后慢慢去寻找

其次，跟业务协商、定下测试相关的指标

  1. qps : 每秒查询数 → 这个指标一般用在数据库上 , 不过很多人都把这个和TPS混淆,这个知道怎么会是就行了
  2. tps : 每秒内的事务数 → 执行多组操作的性能 → 也是数据库的一个指标 , 不过呢我们可以把我们的后台接口操作想象成一个事务 , 所以这个指标是标准的
  3. pv : 只的是调用次数
  4. RT : 接口的响应时间
  5. cpu使用率 : 大家都懂
  6. cpu loading指数 : 这个指标比较重要 , 能反映出cpu当前的"疲劳"程度 , 当前cpu处理任务数量 , 一般最大都要保证内核数量*1.2一下
  7. 内存 : 大家都懂
  8. 出向和入向流量 : 大家都懂

如何获得指标

使用常用的压测工具都可以 , Jmeter、Locust等等 , 这类操作工具都会将qps 或者 tps , RT 整理统计出来 , 这里就不展开了。

制定压力层级和对应的指标

在压测过程中性能(QPS/TPS)的随着压力的变化曲线应该是一个波浪状的

找出了预估的并发大小之后(一般是一个5的倍数的并发数) , 以这个为基准 , 增加多少并发 , 减少多少并发 , 列成表格 , 注意记录各种性能的指标

比如 :

接口|并发数量|压测时间|tps/qps|pv|RT(min)|RT(max)|RT(average)|RT(median) | cpu loading | cpu 使用率 ----|------|-------|-------|—|------|-------|------------|--------- | ------------|------------ get_list|10 |60s | 3000 |1w |1ms |30ms | 15ms |20ms | 6 | 100%

注意 : 这个得出的性能(qps/tps)信息最后至少有一个下降的维度 , 是一个波浪状的效果 , 这样才能找到性能的极限
注意 : 最终性能要使用有效数据 , 如果RT 超过限制或者cpu loading 超过了限制 , 那么这个数据认为不达标 , 但是这个可以用作统计分析

性能瓶颈定位

影响性能的原因有多种 , 不一定真的是系统本身的问题

通过上面的制定压力层级和对应的指标 , 我们已经可以确定了我们当前系统的极限性能了 , 我们不禁想问这些真的是我们的极限性能了吗?

其实我们通过 cpu loading qps tps RT PV 等其实已经能确定当前场景下的一个最佳性能了 , 接写来就需要进行性能问题排查调优

瓶颈排查：

  1. 排查日志 , 找到耗时过长逻辑 , 定位分析 , 比如java系的系统可以使用 alibaba 开源的在线性能分析工具 [arthas]
  2. 排查网络问题 : 当确认代码逻辑没有问题的时候 , 网络延迟过高也会影响qps , 比如跨机房调用等 . 这个时候需要找运维同学协助解决 , 做部署迁移 , 搭建专用线路等方法
  3. 最后 cpu瓶颈 : 这个时候只能通过加机器解决

性能调优：

这个步骤就很多了, 要针对自己的技术栈进行操作 , 比如 java 可修改jvm参数 , 看一下 jvm GC , 内存状态 , 分别对应的进行一下调优 . ps java真多… …

  1. qps上不去问题可能并不是后台的事情 , 不同类型的系统间的相互调用也可能会导致性能问题
  2. 性能瓶颈定位-压测的时候压力机器也要注意 , 有的时候瓶颈可能是压力机器的
5

压力测试是测试一个系统在各种负载下的性能表现。在进行压测之前，需要进行一些准备工作：

  1. 设计测试场景：确定测试的目的、测试方案和测试数据。测试场景需要考虑用户数量、操作类型、时间长度、流量大小等因素。

  2. 确定测试环境：选择测试环境和测试工具，以确保测试的准确性和可靠性。测试环境应该与实际生产环境相似。

  3. 准备测试数据：准备典型的测试数据，以反映真实环境中的数据。

  4. 确定测试指标：确定要测量的指标，例如响应时间、吞吐量和并发用户数等。

  5. 预测系统负载：根据实际情况估计预计的用户量和流量，以确定系统负载的界限。
    除了上述准备工作和处理方法外，还可以：

  6. 确保测试数据的真实性和多样性。测试数据应该反映实际环境中的数据，包括各种数据类型和数据大小。

  7. 在测试前进行预热。在开始测试前，可以先进行一些预热操作，如缓存数据、预热缓存和数据库连接等，以确保测试结果的准确性和稳定性。

  8. 监控系统运行状况。在测试过程中，需要不断地监控系统运行状况，包括服务器资源使用情况、响应时间、错误率和并发用户数等指标，以及日志记录等信息。

  9. 分析测试结果。在测试完成后，需要对测试结果进行分析，包括性能指标、异常情况和优化建议等，以提高系统性能和稳定性。

  10. 预测系统的未来负载。在进行压测时，需要考虑系统的未来负载，包括用户增长、数据增长和业务扩展等因素，以确保系统具有可扩展性和可靠性。

在进行压测时，可能会遇到以下问题：

  1. 响应时间变慢：原因大致为 系统资源不足、数据库连接池满、网络带宽限制等。
  2. 内存泄漏：原因大致为 未释放内存、程序中有死循环、代码中有内存泄漏等。
  3. 并发用户数过高：原因大致为 数据库连接过多、缓存瓶颈、线程池满等。
  4. 网络带宽不足：原因大致为 测试数据量过大、网络拥塞等。
  5. 系统崩溃或出错：原因大致为 代码中的 Bug、系统配置错误等。

针对这些问题，可以通过以下方法进行分析和定位：

  1. 使用性能测试工具：可以使用性能测试工具记录和分析性能指标和测试结果，包括响应时间、吞吐量、并发用户数等。
  2. 日志分析：通过分析系统日志可以发现潜在的问题和错误，如内存泄漏、代码异常等。
  3. 压力测试环境监控：可以使用监控工具对系统进行监控，包括 CPU、内存、网络带宽等指标，以发现性能瓶颈。
  4. 代码分析：通过代码审查和分析可以发现代码中存在的性能问题和潜在的错误。
  5. 系统配置检查：检查系统的配置文件和参数，确保其正确性和合理性。

总结：
进行压测需要进行充分的准备工作，并在测试过程中不断监控和分析测试结果，以提高系统的性能和可靠性。
在压力测试过程中，需要不断地监控和记录测试结果，发现潜在问题和性能瓶颈，并针对性地采取相应的措施解决问题。同时，还需要对测试结果进行分析和总结，以便进行优化和改进。

6

以下是在压测之前需要做的准备工作：

  1. 设计好测试计划和测试场景，明确测试目的和测试指标。
  2. 确认测试环境是否配置正确，包括硬件资源（服务器、网络等）和软件资源（数据库、应用服务器、缓存等）。
  3. 准备压测工具和测试脚本，并进行相关的参数配置和初始化。
  4. 确认测试数据的准确性和完整性，清理无用数据。

在进行压测时，我们需要注意以下方面：

  1. 监控测试指标，例如吞吐量、响应时间、错误率等，及时发现异常。
  2. 观察系统瓶颈位置。例如，假如 CPU 达到了 100%，则系统瓶颈可能在于 CPU;当网络带宽使用率很高时，则瓶颈可能在于网络。
  3. 收集和分析测试数据，包括原始数据和统计数据。通过这些数据，我们可以了解系统性能的瓶颈、读写比例、各层的响应时间等，为针对性优化做好准备。

当我们遇到问题时，我们需要对问题进行分析，找到问题的原因和解决方案。以下是常见的问题分析方法：

  1. 系统日志分析：分析服务端计算机或系统的日志，以确定是否存在异常或错误。
  2. 监控工具分析：通过监控工具，如 Zabbix、Grafana 或 ELK 等，监控系统性能，找到系统瓶颈位置。
  3. 代码分析：查看代码，特别是可能导致性能问题的部分，并进行优化或调整。
  4. 压测数据分析：分析压测数据并定位响应时间慢、局部性能不佳的原因所在层。

总之，在压测之前，最重要的是进行足够的准备和规划。在压测过程中，要做好监控和数据收集工作，及时发现和定位问题。对于求稳的应用，压测不应该只是停留在"看看能秒杀几个Walmart"这个阶段，它需要针对性地分析，厘清问题，通过迭代来稳定应用的性能以及更好地满足用户的需求。

7

一、压力测试的定义

压力测试是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整。并对系统资源进行优化。

二、软件性能的衡量标准

软件的性能可以通过响应时间、并发用户数、吞吐量、资源利用率等性能指标来衡量。

(1)响应时间：

是指用户从客户端发出请求到接收完服务器返回结果的整个过程所需花费的时间，包含网络传输时间以及服务器处理时间。从用户角度来看，响应时间应该从客户端计算机处理用户操作并发出请求到客户端程序收到服务器端返回结果并显示出来的时间。

(2)并发用户数：

是指在一定时间内，某一时刻同时与服务器进行会话操作的用户数，并发用户数的类型包括：系统用户数、同时在线用户数，业务并发用户数。

(3)吞吐量：

是指单位时间内，系统处理用户的请求数或页面数量，可以直接反映出软件的承载能力。一般来说，利用每秒钟的请求数或页面数量衡量吞吐量；从业务的角度来看，也可以用每天的访问人数或每小时处理的业务数来衡量。

(4)资源利用率：

是指系统资源（CPU、内存）的利用率，通常用资源的实际使用量与总的资源可用量比值来衡量，包括网络、操作系统、数据库等方面。

以上四种性能指标主要可分为系统资源利用率和系统行为（响应时间、吞吐量等）两个方面。它们之间存在一定的相关性，共同反映出性能的不同方面。比如，响应时间、最大并发用户数、吞吐量和资源利用率可以分别用来衡量软件的及时性、扩充能力和容量、处理能力、运行状态。响应时间越短、承受的并发数越多、吞吐量越大、占用的资源越少，表明系统性能越好，反之性能越差。

三、测试准备
1.软硬件环境的准备：如服务器、压测工具的选择（jmeter、locust、Loadrunner…）等。

2.测试数据的准备

测试数据准备比较典型的，能反映用户真实环境中的数据，一般最好来源于用户的真实高频数据。

3.编写压力测试计划

编写压力测试计划分为三个阶段：分析数据库应用系统、定义压力测试对象与目标、定义性能测试场景、评审修改压力测试计划。

分析应用系统：一要搞清系统对各个资源的分布和使用情况，它将帮助确定可能系统性能的瓶颈；二是用户在事务中的分布，它将确定压力测试的针对点。

定义压力测试目标：测定终端用户事务的响应时间、定义主机最优配置(如内存、CPU、缓存、适配等)、寻找瓶颈(通过压力测试，要找到降低系统响应时间的因素。是资源竞争导致死锁，还是数据库服务器数据锁设置不好，还是网络传输问题?)。

定义性能测试场景：性能测试的场景的描述是，在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期

评审修改压力测试计划：压力测试计划完成后，要对其进行评审。压力测试计划书的评审人员应包括有经验的用户，软件需求分析员，系统设计员，系统开发员，软件测试员，然后根据评审意见修订并完成测试压力计划书。

4.编写压力测试案例

压力测试案例是完成一个测试目的的一组测试时间的序列，测试案例要包括以下几个要素：测试目的，测试环境，测试数据，测试运行程序(可以是脚本)，预期结果等。

5.多进程模拟多用户

压力测试的执行通常是通过自动化工具执行脚本，或通过发包程序发送数据包实现的。前者是通过多进程运行相同或不同的测试脚本，来模拟多个用户执行相同或不同的任务，实现压力测试。后者要求熟悉数据包的格式，并进行设置。

6.设置并发点

一个测试脚本常常包含多个事务，即使多个进程同时运行一个脚本，也难以保证脚本内的某个事务同时运行，这将影响对这个事务的响应时间的测试。为了解决这个问题，需要没置并发点，先运行到并发点的进程将等待，当所有进程都运行到并发点时，进行释放，使所有的进程同时运行同一个事务，这样就可以测定与实际比较接近的响应时间。

7.运行测试程序并监测系统资源

运行压力测试时还需监测系统资源，监测的对象有：网络阻塞情况、主机CPU使用情况、内存使用情况、缓存使用情况、数据库系统中的数据锁、回滚段、重做日志缓冲区等。监测的结果包括图像与数据文件，并且图像可以实时显示，也可运行结束后分析。

四、问题分析

1.常见的性能问题

1.1 硬件上的性能瓶颈

一般指的是CPU、内存、I/O读写速率，磁盘空间方面的问题。

1.2 网络上的性能瓶颈：

一般指的网络带宽，网络波动，延时，丢包等。

1.3 应用程序上的性能瓶颈

一般指的是开发人员新开发出来的应用程序。

例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。

1.4 数据库的性能瓶颈

一般指的是数据库索引，锁，表空间，慢sql，数据量等影响。

1.5 中间件的性能瓶颈：

比如：超时设置，线程池设置，缓存策略，最大连接数，负载均衡策略等等。

2.如何分析

2.1 容量测试过程中cpu过高

1）用top实时监控cpu使用情况。一般情况下cpu使用率指标是不能超过70%，压测过程中， cpu使用率过高，超过70%以上。

2）分析是use cpu过高还是sys cpu过高，常见的是use cpu使用过高。

3）如果是use cpu使用过高，先把消耗cpu最多的进程找出来（top命令，vmstat），再找到该进程下消耗cpu过高的线程（top -H -p 进程号）或者（ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu命令查找占用cpu高的线程），再把该线程转换成16进制（printf “%x\n” 线程号），再用jstack命令来dump线程栈，看这个线程栈在调用什么东西导致use cpu过高（jstack 进程号 | grep 16进制的线程号）。

4）如果是sy cpu过高，首先查看磁盘繁忙程度、磁盘的队列（iostat、nmon），查看在没有做压测的情况下，sy cpu的使用情况，如果还是较高，则使用strace查看系统内核调用情况，找到系统耗cpu的原因（strace -p 进程号）。

2.2 内存溢出（堆溢出、栈溢出、持久代溢出）之堆内存溢出

1）稳定性压测一段时间后，LR报错，日志报java.lang.OutOfMemoryError.Java heap space。

2）首先检查JVM配置参数，如果参数设置太小，则需要修改JVM参数，修改xms，xmx，调整堆内存参数，一般是增加堆内存。

3）用jmap -histo pid> test.txt命令dump堆内存使用情况，并且保存到test.txt文件中，查看堆内存排名前20个对象，看是否有自己应用程序的方法，从最高的查起，如果有则检查该方法是什么原因造成堆内存溢出，排查可能的原因。

4）如果前20里没有自己的方法，则用命令：jmap -dump:live,format=b,file=test.dump pid生成dump文件，然后使用MAT进行分析dump下来的堆内存，分析导致内存溢出的方法。

5）如果怀疑是内存泄漏，也可以使用JProfiler连上服务器在开始跑压测，运行一段时间后点击“Mark Current Values”，后续的运行就会显示增量，这时执行一下GC，观察哪个类没有彻底回收，基本就可以判断是这个类导致的内存泄漏。

解决：优化代码，对象使用完毕，需要置成null。

2.3 栈内存溢出

1）稳定性压测一段时间后，LR报错，日志报Java.Lang.StackOverflowError。

2）原因可能是递归没返回，循环调用造成。

3）修改jvm参数，将xss参数改大，增加栈内存。

4）栈溢出一定是做批量操作引起的，减少批处理数据量。

2.4 持久代溢出

1）稳定性压测一定时间后，日志报Java.Lang.OutOfMenoryError.PermGen Space。

2）这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多，将持久代占满导致持久代溢出。

3）修改jvm配置，将XX:MaxPermSize参数调大。尽量减少静态变量。

2.5 系统内存溢出

现象：压测执行一段时间后，日志中有报错信息：java.lang.OutOfMemoryError: unable to create new native thread。

原因：操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。

解决：

（1）减少堆内存

（2）减少线程数量

（3）如果线程数量不能减少，则减少每个线程的堆栈大小，通过-Xss减小单个线程大小，以便能生产更多的线程。

2.5 线程死锁

现象：容量测试压测一段时间后，LR报连接超时错误。

原因：造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时的错误。

分析：

1）使用jstack命令查看Java进程下所有线程的情况（jstack -l 进程号），查询线程栈里有没有block，如果有的话就是线程死锁，找到死锁的线程，分析对应的代码。如果大量线程都是Waiting状态，则需要去关注数据库和中间件，可能会有排队情况。

2）查看TCP连接情况（netstat -an |awk '/tcp/

Unknown macro: {print $6}

'|sort|uniq -c ），用netstat -nat|grep -i “端口”|grepTIME_WAIT|wc -l命令查看TIME_WAIT情况，如果TIME_WAIT的值很大并且一直增加的话，说明tcp不能正常释放，会造成响应时间增加。

2.6 数据库死锁

现象：容量测试压测一段时间后，LR报连接超时错误。

原因：造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

分析：查看数据库日志，看有没有死锁的情况：show engine innodb status\G。数据库日志中搜索block，能搜到block的话就是存在数据库死锁，找到日志，查看对应的sql，优化造成死锁的sql。

2.7 数据库连接池不释放

现象：容量测试压测一段时间后，LR报连接超时错误。

原因：造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

解决：

去mysql数据库查看应用程序到数据库的连接有多少个

呈现代码宏出错: 参数’com.atlassian.confluence.ext.code.render.InvalidValueException’的值无效

通过命令：

show variables like ‘%max_connections%’; 查询设置的最大连接数；

show status like 'Threads%'查询当前的连接数是多少

show processlist/show full processlist;

如果当前连接数大于等于最大连接数，说明数据库连接池被占满，需要把最大连接数修改大一点

呈现代码宏出错: 参数’com.atlassian.confluence.ext.code.render.InvalidValueException’的值无效

一般在/etc/my.cnf里面修改 max_connections = xxxx

或通过命令：set global max_connections=xxxx 进行设置

复测看是否还会出现问题，如果出现去数据库查看连接，如果当前连接数大于等于最大连接数，则可以确定是数据库连接池不释放导致的。查看代码，数据库连接部分是不是有创建连接但是没有关闭连接的情况。基本就是这种情况导致的，修改代码即可。

2.8 数据库连接失效

现象：No operations allowed after connection closed，日志发现此报错，问题出在mysql。

原因：数据库的连接被创建后，如果没有手动关闭连接，mysql默认是8小时之后回收连接，如果超过8个小时，应用程序不去访问数据库，数据库就会断掉连接，当程序调用此连接时，到数据库才发现，此连接已经失效了，这时访问就会抛出此异常。

解决：涉及两个参数interactive_timeout和wait_timeout，默认是8小时，延长时间。修改mysql配置文件：vi /etc/my.cnf， 在[mysqld]区域添加这两项，然后重启数据库解决。

2.9 TPS上不去

1）网络带宽

在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。可以通过：直接复制文件传输到另一台服务器 初步查看网速是否达到网络带宽上限（scp -r -P 端口号 root@123.123.123.123：/root/

如网络带宽为100M时，可传输的最大网速为 12M/s 左右。

2）连接池

最大连接数太少，造成请求等待。连接池一般分为服务器中间件连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3）垃圾回收机制

从常见的应用服务器来说，比如Tomcat，如果堆内存设置比较小，就会造成新生代的Eden区频繁的进行Young GC，老年代的Full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收时通常会暂停所有线程的工作。

4）数据库

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。

5）硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

6）压力机

比如Jmeter和Loadrunner，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

7）业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长也会导致TPS上不去。

2.10 TPS波动大

出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。

性能测试环境一般都是在内网或者压测机和服务在同一网段，可通过监控网络的出入流量来排查；（局域网可以不考虑）

其他服务资源竞争也可能造成这一问题，可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争；

垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查（jstat -gc PID 300 10）

2.11 压测过程中TPS不断下降，CPU使用率不断降低

原因：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；

解决：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

2.12 响应时间长，SQL使用不合理

压测过程中，LR结果显示事务响应时间长

针对mysql：首先打开数据库的慢查询，通过命令找到执行比较久的SQL语句：mysql dump slow；分析是由于索引问题还是其他问题。

针对oracle：我们可以打AWR报告，通过报告分析，主要关注SQL ordered by Elapsed Time和SQL ordered by CPU Time两项，找出数据库sql问题。

2.13 服务器压力不均衡（相差1%-2%是正常的）

  • 一般情况下，多台服务器资源相差不大，如果压测的时候，多台应用服务器中只有一台cpu超过60%，其他的都在60%以下。
  • 通过top查看除了应用进程本身，是否还有其他耗cpu较高的进程。
  • 查看cpu超过60%的服务器是否有定时任务。
  • 查看是否存在压力机瓶颈。
  • 是否存在带宽瓶颈（局域网不考虑此问题）。
  • 查看部署的版本，配置是否一样。
  • 可能别人也在用这些AP，因为同一台物理机上有很多虚拟机，因为别人先用，资源被别人先占了。
  • 查看负载均衡策略

2.14 压测过程中，出现大量5xx错误

现象：在压测过程中，服务器返回500错误

分析：500错误表示服务器内部错误，出现此错误时，我们首先查看服务器日志，通过错误日志信息定位具体错误的原因，如果出现get null from pool，说明数据库成为瓶颈，连接数不够导致，此时可以通过调整数据库连接池大小解决。

现象：在压测过程中，服务器返回502错误

分析：502一般是网关错误，同时nginx中会出现Connection reset by peer,出现此类报错的常见原因有：并发数大于服务端最大连接数，服务端会将其中一些连接关闭掉。

3 个赞
8

准备工作：

  1. 确定测试目的和测试需求，明确测试的重点和性能指标。
  2. 确定测试环境，包括硬件配置、网络带宽、操作系统等。
  3. 准备测试数据，尽可能真实地模拟实际使用场景。
  4. 配置压力测试工具，例如JMeter、LoadRunner等。
  5. 设置监控工具，如性能监测工具、日志监控工具等。
  6. 编写测试脚本，根据测试需求编写压力测试脚本。

分析问题：

  1. 查看测试结果，判断是否出现性能问题。
  2. 定位问题，通过排查日志和监控数据，找出性能问题的根源。
  3. 分析问题原因，分析性能问题的具体原因，例如网络延迟、服务器负载过高等。
  4. 优化解决问题，通过优化测试环境、代码、数据库等，解决性能问题。
  5. 重新测试验证，再次进行压力测试，验证性能问题是否已经解决。
9

在进行压力测试之前，需要做以下准备工作：

  1. 确定测试目标：确定测试的目的，例如确定应用程序的性能瓶颈，测试新功能的性能等。
  2. 确定测试场景：根据测试目标，选择适当的测试场景，并设置测试参数，例如请求量、请求频率、用户数量等。
  3. 准备测试环境：创建测试环境，包括应用程序、数据库、缓存、文件系统等。
  4. 准备测试数据：准备测试数据，模拟真实的用户场景和负载情况。测试数据可能包括用户数据、产品数据、交易数据等。
  5. 准备测试工具：根据测试场景和测试目标，选择适当的测试工具，并配置测试工具。

执行压力测试的步骤如下：

  1. 启动测试工具：根据测试方案，选择适当的测试工具，并启动测试工具。
  2. 监控测试结果：在测试期间，需要监控测试结果，例如响应时间、吞吐量、并发用户数、CPU利用率、内存利用率等。

分析测试结果的步骤如下：

  1. 对比基准：将测试结果与基准进行对比，并分析性能差异。基准可能是先前的测试结果，也可能是生产环境的性能数据。
  2. 识别瓶颈：根据测试结果，识别应用程序和基础设施的瓶颈。例如，瓶颈可能是网络带宽、数据库性能、缓存命中率等。
  3. 优化应用程序：根据瓶颈，优化应用程序。例如，改进代码、优化数据库查询、提高缓存命中率等。
  4. 优化基础设施：根据瓶颈，优化基础设施。例如，升级硬件、优化网络配置、调整操作系统参数等。
10

需要进行以下准备工作：

确定压测目的：需要明确压测的目标，比如检验系统性能、确定系统容量、测试系统的可靠性等。

制定测试计划：包括测试环境的搭建、测试场景的设计、测试数据的准备等。

准备测试工具：选择合适的性能测试工具，比如JMeter、LoadRunner等，根据测试计划进行工具配置。

确定测试指标：包括并发用户数、响应时间、吞吐量、错误率等指标。

模拟真实场景：尽可能模拟真实的用户场景，包括并发访问、请求类型、请求数据大小等。

当遇到问题时，可以从以下几个方面进行分析：

查看测试日志：测试日志中可以得到大量的数据，包括测试结果、请求响应时间等信息，可以通过对日志进行分析，找出问题所在。

原因排查：排除网络故障、服务端故障等因素，尽可能缩小问题的范围。
11

在进行压力测试之前，准备测试数据是非常重要的一步。以下是一些准备测试数据的方法：

准备测试数据的方法 描述
生成随机数据 使用随机数据生成器来生成测试数据，确保数据的多样性和充分性。
使用真实数据 使用真实的数据来模拟真实场景，并确保数据的安全性和隐私性。
数据库复制 从生产环境中复制一份真实数据到测试环境中，以模拟真实的测试环境。
数据库还原 从备份中还原一份数据到测试环境中，以模拟真实的测试环境。
数据库填充 使用脚本和工具来填充测试数据，确保数据的充分性和多样性。

在准备测试数据时，还需要注意以下几点：

数据准备时的方法 描述
数据的准确性 确保测试数据的准确性和完整性，以避免测试结果的误差。
数据的安全性 确保测试数据的安全性和隐私性，避免泄露敏感信息。
数据的多样性 确保测试数据的多样性和充分性，以模拟真实的测试环境。

在进行压测之前，需要做以下准备：

压测前准备 描述
确定测试目标 明确压测的目标，包括测试系统的性能、稳定性、吞吐量等方面的指标，以便于设计测试方案和评估测试结果。
确定测试场景 根据实际场景，设计测试场景，包括用户数量、请求类型、请求频率、请求参数等，以尽可能模拟真实的业务场景。
准备测试环境 搭建测试环境，包括部署应用程序、数据库、缓存、负载均衡等组件，以便于进行测试。
设置测试工具 选择合适的测试工具，如JMeter、LoadRunner等，并进行配置和调试，以便于进行测试。
编写测试脚本 根据测试目标和测试场景，编写测试脚本，包括模拟用户请求、处理请求结果、输出测试结果等，以便于进行自动化测试。

在进行压测时，可能会遇到以下问题：

压测可能遇到的问题备 描述 解决方法
性能瓶颈 测试结果显示系统的性能不足或存在瓶颈，此时需要对系统进行优化和调整，以提高系统的性能和稳定性。 通过分析测试结果，确定系统存在的问题和瓶颈，并采取相应的优化和调整措施。
响应时间过长 测试结果显示系统的响应时间过长，此时需要对系统进行优化和调整，以缩短响应时间和提高用户体验。 对于资源耗尽的问题，可以增加系统的资源，如增加CPU、内存、磁盘等，以满足系统的需求。
资源耗尽 测试过程中可能会出现资源耗尽的情况，如CPU、内存、磁盘等资源的耗尽，此时需要对系统进行优化和调整，以避免资源浪费和系统崩溃。 对于系统响应时间过长的问题，可以对系统进行优化和调整，如调整系统参数、优化数据库查询语句等，以提高系统的响应速度。
网络问题 测试过程中可能会出现网络问题，如网络延迟、网络抖动等，此时需要对网络进行优化和调整，以提高网络的稳定性和可靠性。 对于网络问题，可以对网络进行优化和调整，如调整网络带宽、增加网络设备等，以提高网络的稳定性和可靠性。
1 个赞
12

jmeter在遇到单机性能瓶颈的时候，怎么实现压力测试？