性能测试中常见缺陷及TPS上不去的原因浅析
性能测试问题解决方法-19种情况
一、Error-27727:Step downlo ad timeou t (120 second s)has expire d whendownlo ading resour ce(s). Set the “Resour ce Page Timeou t is aWarnin g” Run-Time Settin g to Yes/No to have this messag e as awarnin g/error, respec tivel y处理方法：Run-Time Settin g ------ Intern et Protoc ol ------ Prefer ences------Option ------ Step downlo ad timeou t(sec)改为32000A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大或多二、错误现象：Action.c(16): Error-27728: Step downlo ad timeou t (120 second s) has expire d when downlo ading non-resour ce(s)。
错误分析：对于HTTP协议，默认的超时时间是120秒（可以在Loa dRunn er中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。
解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"Runtim e Settin g">"Intern et Protoc ol：Prefer ences">"Advanc ed"区域中设置一个"winlne t replay instea d of socket s"选项，再回放是否成功。
性能测试之TPS趋势分析（三）
性能测试之TPS趋势分析（三）理解TPS趋势分析在性能分析中，前端性能⼯具，我们只需要关注⼏条曲线就够了：TPS、响应时间和错误率。
这是我经常强调的。
但是关注TPS到底应该关注什么内容，如何判断趋势，判断了趋势之后，⼜该如何做出调整，调整之后如何定位原因，这才是我们关注TPS的⼀系列动作。
今天，我们通过⼀个实际的案例来解析什么叫TPS的趋势分析。
案例描述这是⼀个案例，⽤⼀个2C4G的Docker容器做服务器。
结构简单⾄极，如下图所⽰：当个⼈电脑（上图中的压⼒⼯具1）测试云端服务器时，达到200多TPS。
但是当⽤云端同⽹段压⼒机（上图中压⼒⼯具2）测试时，TPS只有30多，并且内⽹压⼒机资源⽐本地压⼒机资源要⾼出很多，服务器资源也没有⽤完。
在这样的问题⾯前，期通常都会有⼀堆的问题要问。
1. 现象是什么2. 脚本是什么3. 架构是什么4. ⽤了那些监控⼯具5. 看了那些计数器在分析之前，这些问题都是需要收集的信息，⽽实际上在分析过程中，我们会发现各种数据的缺失，特别是远程分析的时候，对⽅总是不知道应该给出什么数据。
我们真多这个案例实际说明⼀下。
这个案例的现象是TPS低，资源⽤不上。
下⾯是⼀个RPC脚本的主要代码部分。
JMeter脚本关键部分在这个脚本中，逻辑⾮常简单，⼀个RPC接⼝：1.发出请求2.返回响应3.打印返回信息。
本机跑出来的结果如下：在这个案例中，参数化数据就是根据真实的业务量来计算的，这个可以肯定没有问题。
那么架构呢？在最上⾯的图中已经有了部署的说明。
在逻辑实现上，也就是⼀个很简单的服务端，内部并没有复杂的逻辑。
所⽤到的监控⼯具是top、Vmstat。
看了CPU、内存、I/O等计数器。
下⾯我们开始分析。
第⼀阶段对公⽹的测试来说，基本上压⼒都会在⽹络上，因为出⼊⼝带宽会成为瓶颈，所以先要看⼀眼⾃⼰的带宽⽤到了多少，再⽐对⼀下出⼝路由上的带宽。
这⾥1Gbps只⽤到了0.01%，也就是（1000/8）*0.01%=12.5k（这⾥是将带宽bit换成byte计算）在这样的带宽使⽤率之下，即使是公⽹也不见得会有问题，更别说实在内⽹了。
性能测试常见问题分析
性能测试常见问题分析⼀、内存溢出1、堆内存溢出现象： （1）压测执⾏⼀段时间后，系统处理能⼒下降。
这时⽤JConsole、JVisualVM等⼯具连上服务器查看GC情况，每次GC回收都不彻底并且可⽤堆内存越来越少。
（2）压测持续下去，最终在⽇志中有报错信息：ng.OutOfMemoryError.Java heap space。
排查⼿段： （1）使⽤jmap -histo pid > test.txt命令将堆内存使⽤情况保存到test.txt⽂件中，打开⽂件查看排在前50的类中有没有熟悉的或者是公司标注的类名，如果有则⾼度怀疑内存泄漏是这个类导致的。
（2）如果没有，则使⽤命令：jmap -dump:live,format=b,file=test.dump pid⽣成test.dump⽂件，然后使⽤MAT进⾏分析。
（3）如果怀疑是内存泄漏，也可以使⽤JProfiler连上服务器在开始跑压测，运⾏⼀段时间后点击“Mark Current Values”，后续的运⾏就会显⽰增量，这时执⾏⼀下GC，观察哪个类没有彻底回收，基本就可以判断是这个类导致的内存泄漏。
解决⽅式：优化代码，对象使⽤完毕，需要置成null。
2、永久代 / ⽅法区溢出现象：压测执⾏⼀段时间后，⽇志中有报错信息：ng.OutOfMemoryError: PermGen space。
产⽣原因：由于类、⽅法描述、字段描述、常量池、访问修饰符等⼀些静态变量太多，将持久代占满导致持久代溢出。
解决⽅法：修改JVM参数，将XX:MaxPermSize参数调⼤。
尽量减少静态变量。
3、栈内存溢出现象：压测执⾏⼀段时间后，⽇志中有报错信息：ng.StackOverflowError。
产⽣原因：线程请求的栈深度⼤于虚拟机所允许的最⼤深度，递归没返回，戒者循环调⽤造成。
解决⽅法：修改JVM参数，将Xss参数改⼤，增加栈内存。
栈内存溢出⼀定是做批量操作引起的，减少批处理数据量。
性能测试中常见的问题和解决方案
性能测试中常见的问题和解决方案性能测试是软件开发过程中非常重要的一环，它可以帮助开发团队评估系统在真实环境下的性能和稳定性。
然而，性能测试中常常会遇到一些问题，如何解决这些问题成为了测试团队面临的挑战。
本文将介绍性能测试中常见的问题和解决方案，并给出相应的案例分析。
一、性能测试中的常见问题1. 测试环境的复杂性：性能测试需要在真实的环境中进行，这意味着测试团队需要考虑服务器、网络、数据库等各种因素。
在搭建测试环境时，很容易出现配置错误、资源不足等问题。
2. 测试数据的准备：性能测试需要使用大量真实数据进行测试，但是获取和准备测试数据是困难的。
测试数据的大小、类型和分布等都会影响测试结果的准确性。
3. 测试工具的选择：性能测试需要使用合适的测试工具进行测试，但是市面上的测试工具种类繁多，选择合适的工具成为了一个难题。
4. 测试负载的设计：测试负载是性能测试中一个重要的因素，如何设计合理的测试负载是性能测试的关键。
如果测试负载过轻，可能无法发现系统的性能瓶颈；如果测试负载过重，可能会导致系统崩溃。
5. 测试结果的分析与解读：性能测试的结果往往是一个庞大的数据集，如何从中提取有用的信息，分析系统的性能瓶颈，并给出相应的优化建议，是测试团队需要面对的难题。
二、性能测试中的解决方案1. 搭建稳定可靠的测试环境：在搭建测试环境时，需要遵循一定的规范，配置正确的服务器、网络和数据库等。
同时，通过监控和性能分析工具来及时发现和解决配置错误和资源不足等问题。
2. 测试数据的准备：为了准备合适的测试数据，测试团队可以使用模拟数据生成工具和数据脚本等。
同时，测试数据的大小、类型和分布应该与真实环境尽量接近，以提高测试的准确性。
3. 选择合适的测试工具：在选择测试工具时，需要考虑测试需求、测试目标和预算等因素。
对于不同的测试需求，可以选择不同类型的测试工具，如负载测试工具、性能监控工具等。
4. 合理设计测试负载：在设计测试负载时，需要考虑系统的特点和使用场景。
性能测试瓶颈分析
性能测试瓶颈分析你好，我是⼩⽜，⽬前在⼀家准⼀线互联⽹⼤⼚做测试开发⼯程师。
对于⼀般公司普通测试⼯程师来说，可能性能测试做的并不是很复杂，可能只是编写下脚本，做个压测，然后输出报告结果，瓶颈分析和调优的事都丢给开发去做。
在⼀些⼤⼚都有专门的性能测试团队去定位分析系统性能瓶颈，并进⾏调优。
但是，这并不意味着对于那些不想进⼤⼚或者限于学历暂时⽆法进⼊⼤⼚的⼈学习性能测试就没有意义了。
相反，我觉得很有意义，⾸先，做性能测试有利于你更好的理解系统架构以及整个链路数据的流转调⽤情况，从⽽加深你对业务的理解，更好的进⾏⼿⼯业务测试。
其次，学好性能测试对于你跳槽找⼯作⾯试来说是⼀⼤利器。
之前不⽌⼀次提过，对于想拿⾼薪或者想进⼤⼚的同学来说，其实就是看你编程，⾃动化，性能这⼏块掌握的怎么样。
⾄于其它⼯具使⽤，测试思维说实话都⽐较虚，也⽐较基础，没什么亮点。
那么接下来详细聊聊如何定位分析性能瓶颈，并调优呢？⾸先，说⼀下相对专业⼀些的性能测试在压测之前⼀般是怎么做的？压测之前，⼀般会先对各个数据流转系统做好监控，⽐如服务器硬件资源cpu，磁盘，⽹络，io以及数据库服务器，数据库连接数，是否有sql慢查询，包括线程状态，JVM，中间件redis，nginx等等做监控。
关于如何做监控就看公司性能测试这块投⼊成本和建设的怎么样了，⽐如有的公司有⾃⼰的监控平台，可以同时监控很多东西。
像⼀些规模不⼤的团队简陋⼀点的可以借助于现有的开源平台和⼯具做监控。
⽐如Grafana+Prometheus可以监控服务器操作系统资源和数据库。
jvisualvm可以监控JVM和线程状态，包括线程阻塞，死锁等等。
nmon可以监控linux服务器，cpu，磁盘，内存，⽹络等。
除了这些⼯具还可以使⽤⼀些命令来做⼀些简单监控，⽐如监控cpu可以⽤top命令，内存⽤free命令等。
监控中间件redis可以⽤info命令，监控nginx连接数使⽤netstat命令等等。
性能测试问题总结
性能测试问题总结在软件开发和系统优化的过程中，性能测试是至关重要的环节。
通过性能测试，我们可以发现系统在处理大量用户请求、高并发场景以及复杂业务逻辑时可能出现的性能瓶颈和问题。
然而，在进行性能测试的过程中，往往会遇到各种各样的挑战和问题。
接下来，我将对常见的性能测试问题进行总结和分析。
一、测试环境问题1、硬件配置不一致在性能测试中，如果测试环境的硬件配置与生产环境存在较大差异，那么测试结果的参考价值就会大打折扣。
例如，生产环境使用的是高性能服务器，而测试环境使用的是配置较低的服务器，可能导致测试结果显示系统性能良好，但在实际生产环境中却出现性能瓶颈。
2、网络环境差异网络环境的不同也会对性能测试结果产生影响。
测试环境中的网络带宽、延迟和丢包率等参数可能与生产环境不同，从而导致测试结果无法真实反映系统在实际网络环境中的性能表现。
3、软件版本不一致测试环境中使用的软件版本与生产环境不一致，可能会引入一些未知的差异。
例如，数据库版本、中间件版本的不同，可能会导致性能表现的差异。
二、测试脚本问题1、脚本逻辑错误性能测试脚本的逻辑如果存在错误，可能会导致测试结果不准确。
例如，没有正确模拟用户的操作流程，或者在脚本中存在重复请求、遗漏关键步骤等问题。
2、参数化不合理在性能测试中，常常需要对一些数据进行参数化，以模拟真实的用户场景。
如果参数化不合理，例如参数取值范围不合理、参数分布不均匀等，可能会导致测试结果无法反映真实的系统性能。
3、关联和断言设置不当脚本中的关联和断言设置不当，可能会导致测试失败或者测试结果不准确。
例如，关联没有正确获取到动态数据，断言设置过于严格或宽松。
三、测试数据问题1、数据量不足如果测试数据量不足，无法模拟真实的业务场景，可能会导致系统在处理大量数据时出现性能问题。
2、数据分布不合理测试数据的分布如果不合理，例如某些数据类型出现的频率过高或过低，可能会影响测试结果的准确性。
3、数据质量问题测试数据中存在错误、重复或不完整的数据，可能会导致系统在处理数据时出现异常，从而影响性能测试结果。
性能分析——精选推荐
性能分析性能结果分析是性能测试中的⼀个重要部分，同时也是⼀个难点。
由于不同的软件系统，不同的性能指标，结果分析⽅法都是不⼀样的。
需要具体问题具体分析。
下⾯将阐述⼀些性能分析的⽅法与建议。
1 性能分析的⽬的1）找出系统瓶颈（硬件、软件）2）提出性能优化⽅案3）达到合理的硬件和软件配置4）使系统资源使⽤达到最⼤平衡2 常见性能瓶颈征兆在性能测试执⾏过程中，我们需要观察和了解系统的运⾏状态，如果出现以下征兆，则表⽰系统可能存在瓶颈。
1) 持续缓慢：应⽤程序⼀直特别慢，改变负载，对整体响应时间影响很少；2) 随着时间推进越来越慢：负载不变，随着时间推进越来越慢，可能到达某个阈值，系统被锁定或出现⼤量错误⽽崩溃；3) 随着负载增加越来越慢：每增加若⼲⽤户，系统明显变慢，⽤户离开系统，系统恢复原状；4) 零星挂起或异常错误：可能是负载或某些原因，⽤户看到页⾯⽆法完成并挂起，⽆法消除；5) 可预见的锁定：⼀旦出现挂起或错误，就加速出现，直到系统完全锁定。
通常要重启系统才解决。
6) 突然混乱：系统⼀直运⾏正常，可能是⼀个⼩时或三天之后，系统突然出项⼤量错误或锁定。
3 性能数据解读建议性能分析过程也是⼀个解读数据的过程，读懂了数据你就能知道问题出在何处。
随着经验的累积将会很容易判断问题的根源，甚⾄在开发阶段就能对可能出现问题的点打预防针。
性能指标类型标准性能瓶颈征兆分析⼯具TPS及其波动范围1.Tps符合性能⽬标2.Tps轨迹波动平稳1.TPS有明显的⼤幅波动，不稳定。
例如TPS轨迹缓慢下降，缓慢上升后骤降，呈瀑布型，呈矩形，分时间段有规律的波动，⽆规律的波动等。
这些TPS的波动轨迹反映出被测试的性能点存在性能瓶颈，需要性能测试⼯程师与开发⼯程师查找性能瓶颈的原因。
2. TPS轨迹⽐较平稳，但是也存在波动现象。
该类波动不明显，很难直接确定是否存在性能瓶颈。
我们需要根据其他指标来进⾏判断。
Jmeter/loadrunner响应时间90%平均事务响应时间<性能⽬标1.关注⾼峰负载时，⽤户操作响应时间；2.关注数据库增量，对⽤户操作响应时间的影响。
TPS常见问题
HoneyWell TPS是美国HoneyWell公司的最新产品，它是在TDC-3000系统基础上发展起来的，以Windows NT4.0为基本操作系统平台，继承了TDC-3000系统的全部功能。
具有开放性强、用户界面友好、方便与第三方软件通讯的优点。
我厂的TPS系统是1998年6月从美国HoneyWell公司引进的原装产品。
本系统用于我Ⅱ催化生产装置的反应、分馏、稳定、脱硫、碱洗、余热锅炉等的过程控制。
经过近几年的摸索和实践，我们碰到一些常见问题并总结出处理办法。
(一) GUS流程图数据调不出或GUS NATIVE WINDOW无数据显示，处理过程如下:（1）调出LCNP面板,做RESET LCNP操作，等待LCNP自检正常后，退出该状态。
（2）在NATIVE WINDOWS 中，按“LOAD”或击键盘上的“LOAD”键。
（3）按LOAD键，待有提示出现时，键入“W”，再等待下一个提示时输入“N”。
（4）等待，直至窗口中显示系统状态画面，调出流程图。
（5）CTL+ALT+DEL，选择LOGOFF，退出登录。
（6）按CTL+ALT+DEL，等待出现对话框，输入帐号、口令。
（7）按ALT+S，访问START菜单，调出NATIVE WINDOW。
(二) 数据点没有显示或数据点显示数据不变，而实际有变化，处理过程如下：（1）调出NATIVE WINDOW，按IKB上的DETAIL键，输入“点名”，如TI101。
（2）NATIVE WINDOW显示点细目。
（3）在点细目上查看以下参数设置：PVSOURCE：AUTO（正常设置）；MAN（会造成点的PV显示不变化）PVRAW：有数值表示现场信号已进入计算机；―――表示现场信号没有进入计算机；负值表示接收到的信号为小信号。
PV：后缀字母红色―表示“B”坏值；黄色―表示“L/H”超低限/高限。
LOCUTOFF：若设定有值，当PV小于该设定值，PV显示“0”值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
性能测试中TPS上不去的原因浅析及常见缺陷
一、TPS上不去原因解析
先来解释下什么叫TPS：
TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。
下面就说说压测中为什么TPS上不去的原因：
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。
连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
丢包：数据在网络上是以数据包的形式传输的，如果丢包，则可能造成报错或异常的情况；
3、应用
（1）、JVM
堆内存分配：根据系统硬件条件来进行合理的堆内存分配，一般来说JVM的堆内存分配不要超过系统内存的25%较好；
垃圾回收算法：JAVA的动态垃圾回收机制，是基于不同的几种回收算法来进行的，根据
具体的情况，选择合适的垃圾回收策略；
OOM：即内存溢出（out of memory），这个算是性能测试中很常见的一个问题，通常
是由于代码问题造成的内存泄漏、GC不够彻底、内存被耗尽引起；
（2）、代码逻辑
常见的情况有不合理的线程引用和内存分配；
4、配置
版本：在性能测试过程中，一定要确保被测系统的版本和实际生产保持一致，否则由于版
本不同带来的些许差异可能会对性能测试带来很大的偏差和影响；
底层配置：涉及到操作系统、服务器等硬件的一些配置方式不合理，带来的性能瓶颈；
参数配置：系统架构设计中，各个不同的参数配置带来的性能瓶颈；
5、数据库
索引：索引的存在就像一个标签目录一样，在执行数据库操作时提供更为快速的执行效率，减少磁盘IO操作和执行的数据库系统时间；
锁：为了保证事务的原子性和隔离性，有了锁的存在，但有时候由于某些原因造成的表锁，也是性能瓶颈的一种表现；
表空间：不合理的表空间设计，导致的数据库性能问题；
慢SQL：慢SQL会导致数据库操作时间变长，增加IO读写以及引起一些列的资源竞争等问题，常见的慢SQL原因如下（以MySQL为例）：
数据量：对同一张表来说，1W条数据和1000W条数据，对其进行操作时的性能表现也
是不同的，因此在性能测试时对于数据的正确性可用性，以及数据量也是需要重点关注的；
6、中间件
超时：设置合理的请求或响应超时时间，是很有必要的，这点要根据具体的业务场景和系
统架构来考虑，具体的超时时间，建议进行配置测试来设定；
线程池：之前的博客介绍过线程池的相关资料，线程池配置太小，很容易被使用完，太大
的话又浪费资源，合理的线程池，建议进行配置测试来确定；
缓存策略：缓存的优点是减少请求响应过程中的传输时间，但有时候在高并发情况下，缓
存很容易失效而导致缓存穿透，瞬间对服务端带来很大的压力；
最大连接数：关于连接数，之前的博客也介绍过，合理的连接数配置是很重要的，否则连
接数太少容易导致队列等待、超时，连接数太多则浪费了系统资源；
通信实现方式：同步（sync）和异步（Async）；
负载均衡策略：现在很多的系统都进行了服务集群，随之而来的就是负载均衡策略的实现，如果负载均衡不够“均衡”，在大数量的冲击下，容易导致某些服务的异常或者挂起；。