性能测试中常见缺陷及TPS上不去的原因浅析

一、Error‎-27727‎:Step downl‎o ad timeo‎u t (120 secon‎d s)has expir‎e d whendownl‎o adin‎g resou‎r ce(s). Set the “Resou‎r ce Page Timeo‎u t is aWarni‎n g” Run-Time Setti‎n g to Yes/No to have this messa‎g e as awarni‎n g/error‎, respe‎c tive‎l y处理方法：Run-Time Setti‎n g ------ Inter‎n et Proto‎c ol ------ Prefe‎r ence‎s------Optio‎n ------ Step downl‎o ad timeo‎u t(sec)改为320‎00A、应用服务参‎数设置太大‎导致服务器‎的瓶颈B、页面中图片‎太多C、在程序处理‎表的时候检‎查字段太大‎或多二、错误现象：Actio‎n.c(16): Error‎-27728‎: Step downl‎o ad timeo‎u t (120 secon‎d s) has expir‎e d when downl‎o adin‎g non-resou‎r ce(s)。

错误分析：对于HTT‎P协议，默认的超时‎时间是12‎0秒（可以在Lo‎a dRun‎n er中修‎改），客户端发送‎一个请求到‎服务器端，如果超过1‎20秒服务‎器端还没有‎返回结果，则出现超时‎错误。

解决办法：首先在运行‎环境中对超‎时进行设置‎，默认的超时‎时间可以设‎置长一些，再设置多次‎迭代运行，如果还有超‎时现象，需要在"Runti‎m e Setti‎n g">"Inter‎n et Proto‎c ol：Prefe‎r ence‎s">"Advan‎c ed"区域中设置‎一个"winln‎e t repla‎y inste‎a d of socke‎t s"选项，再回放是否‎成功。

性能测试之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.关注数据库增量，对⽤户操作响应时间的影响。

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”值。

一、问题现象在对系统测试过程中发现，大并发下，Windows平台部署的Weblogic系统性能远远要高于AIX系统部署Weblogic的性能。

100并发，Windows平台响应时间4～6s，而AIX平台下将近20s，而且，Windows平台的硬件性能远不及AIX系统的性能。

二、问题分析过程分析测试结果，发现AIX脚本下网络流量明显偏低，100并发下仅有3M/s TPS在4～5/s之间，而Windows下，100并发可以达到8M/s，TPS在25～30/s之间。

初步怀疑网络环境存在问题。

使用FTP等工具测试网络带宽使用情况。

发现传输速度在3M/s左右。

进一步确认是由于网络问题造成响应时间不足。

由于两者均在3M/s左右。

是处理能力造成网络吞吐量不够还是由于网络，产生了一个蛋生鸡还是鸡生蛋的问题。

在进一步的分析过程中发现，即使控制并发，确保网络不存在瓶颈。

其TPS也无法提高，维持在原水平不变。

进一步怀疑是处理能力不足。

由于现象难以描述，在网上查询较久，但一直未找到原因。

于是考虑到在各设备、操作系统上安装，试图重现问题，但是一直未能找到问题。

偶然见发现某两台Linux服务器上装的Weblogic响应时间差距很大，与最初的现象相当类似。

检查Weblogic配置。

发现有一台服务器部署的是32位WebLogic，另一台部署的是64位WebLogic。

进一步怀疑是不同版本的WebLogic在部署时由于参数配置不恰当产生的问题。

与此同时，查看Weblogic的日志。

发现有如下的错误：二、问题到此相当的明显！由于没找到performance pack，造成不能使用Native IO，从而影响了系统性能。

三、问题解决查阅Bea的相关文档，有如下的描述：修改$BEA_HOME/weblogic92/common/bin/commEnv.sh这个文件，查找aix段，将LIBPATH指定到包含performace pack的路径下即可。

性能测试问题总结在软件开发和系统优化的过程中，性能测试是一个至关重要的环节。

它能够帮助我们发现系统在处理高并发、大数据量等场景下的潜在问题，从而提前进行优化和改进，确保系统在实际运行中能够稳定、高效地为用户提供服务。

然而，在进行性能测试的过程中，我们往往会遇到各种各样的问题。

下面，我将对一些常见的性能测试问题进行总结。

一、测试环境问题测试环境与生产环境的差异是导致性能测试结果不准确的一个重要因素。

首先，硬件配置的不同可能会对测试结果产生较大影响。

例如，生产环境中的服务器可能具有更高的 CPU 核心数、更大的内存和更快的存储设备，而测试环境中的硬件资源相对有限。

这可能导致在测试环境中表现良好的系统，在生产环境中面临性能瓶颈。

其次，软件环境的差异也不容忽视。

比如，数据库的版本、中间件的配置、操作系统的参数设置等，如果在测试环境和生产环境中不一致，可能会导致性能表现的差异。

此外，网络环境也是一个关键因素。

测试环境中的网络带宽、延迟和丢包率等可能与生产环境存在较大差别，从而影响性能测试的结果。

为了尽量减少测试环境与生产环境的差异，我们应该在搭建测试环境时，尽可能地模拟生产环境的硬件配置、软件版本和网络环境。

同时，在测试过程中，要对环境因素进行详细的记录和分析，以便在发现性能问题时，能够准确判断是否是环境差异导致的。

二、测试用例设计问题测试用例的设计直接关系到性能测试的效果和发现问题的能力。

如果测试用例设计不合理，可能会遗漏一些关键的性能场景，或者无法准确地模拟真实的用户行为。

在设计测试用例时，一个常见的问题是没有充分考虑到系统的业务特点和用户使用习惯。

例如，对于一个电商网站，在进行性能测试时，不仅要测试商品浏览、下单等常见操作，还要考虑促销活动期间的高并发抢购场景。

如果只关注了常规操作，而忽略了特殊场景，可能会导致系统在实际运行中出现性能问题。

另外，测试用例的参数设置也需要谨慎。

比如，并发用户数、数据量、思考时间等参数的设置如果不合理，可能会导致测试结果的偏差。

性能测试中的常见异常分析（转载整理）堆内存溢出ng.OutOfMemoryError: Java heap space原因：java堆内存不够或者程序中有死循环；解决：如果是java堆内存不够，需要通过调整JVM下⾯的配置来解决： < jvm-arg>-Xms3062m < / jvm-arg> < jvm-arg>-Xmx3062m < / jvm-arg>ng.OutOfMemoryError: GC overhead limit exceeded原因：内存不⾜，GC为了释放很⼩空间⽽占⽤⼤量时间时抛出异常解决： 1、查看系统是否有使⽤⼤内存的代码或死循环； 2、通过添加JVM配置，来限制使⽤内存： < jvm-arg>-XX:-UseGCOverheadLimit< /jvm-arg>ng.OutOfMemoryError: PermGen space原因：P区内存不够解决：可通过调整JVM的配置： < jvm-arg>-XX:MaxPermSize=128m< /jvm-arg> < jvm-arg>-XXermSize=128m< /jvm-arg> JVM的Perm区主要⽤于存放Class和Meta信息的,Class在被Loader时就会被放到⽼年代，GC在主程序运⾏期间不会对⽼年代进⾏清理，默认是64M⼤⼩，当程序需要加载的对象⽐较多时，超过64M就会报这部分内存溢出了，需要加⼤内存分配，⼀般128m⾜够ng.OutOfMemoryError: Direct buffer memory原因：栈溢出，⽅法调⽤层次过多或者线程栈太⼩。

解决：优化程序设计，减少⽅法调⽤层次；调整-Xss参数增加线程栈⼤⼩。

调整-XX:MaxDirectMemorySize= 参数< jvm-arg>-XX:MaxDirectMemorySize=128m< /jvm-arg>ng.OutOfMemoryError:PermGen spaceJava异常ThrowableThrowable是 Java 语⾔中所有错误或异常的超类。

性能测试中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）；负载均衡策略：现在很多的系统都进行了服务集群，随之而来的就是负载均衡策略的实现，如果负载均衡不够“均衡”，在大数量的冲击下，容易导致某些服务的异常或者挂起；。

TPS系统常见故障分析及解决办法dcs （ distributed control system）集散控制系统，是上世纪70年代国外推出的自动化控制系统，通常称为dcs，其控制系统的功能是由不同的设备来完成的，当某个设备出现故障时，对整个系统影响降到最低。

tps系统，是美国honeywell公司的一个先进的dcs产品，是将整个工厂商业信息系统与生产过程控制系统统一在一个平台上的dcs自动化控制系统。

可与管理计算机连接，进行远程高级控制和管理。

目前，我公司在用的dcs系统全部为honeywell公司的tps系统。

1 tps系统节点及功能介绍hpm：高性能过程处理器，用于扫描和控制tps系统过程数据。

nim：网络接口模件，提供lcn访问ucn的接口，转换lcn和ucn 的通讯技术和协议。

hm：历史模件，文件服务器，支持lcn网络的系统活动、历史数据存储。

系统事件用于系统性能的观测、调整和故障排除；过程历史数据用于生产过程监控。

gus：全局用户操作站，tps系统的人机界面，继承us的全部功能，基于windows nt4。

0平台（为ntfs分区）的native windows 窗口使用。

控制网络包括局域控制网络lcn和万能控制网络ucn，lcn网实现集中管理，ucn网实现过程功能，与hpm、lm、sm、plc等相连，实现各种控制功能。

2 系统常见故障的分析研究常见故障有四大类：2。

1 通讯故障lcn缆通讯故障；ucn缆通讯故障；i/0 link电缆通讯故障；gus 站与系统间的通讯故障。

产生故障的原因：设备损坏；电缆各种接头松动或脱开（常见故障）；外来电磁信号的干扰（ lcn接地不好，经常出现故障）。

处理问题的措施：更换设备；重新将电缆进行连接，并用专用工具进行紧固；做好接地，满足系统的要求。

2。

2 硬件故障hpmm卡件或i/o卡件整个损坏（状态灯不亮）；1/o卡件部分损坏，如坏某个通道（状态灯闪烁）；操作站的硬盘，显卡，网卡等的损坏；其它设备的损坏。

性能测试-详细的TPS调优笔记概述
在本地针对项⽬的登录接⼝做了⼀次简单的压⼒测试。

200并发持续120s，观察吞吐量
运⾏结束之后，吞吐量是这样的
如图所⽰，吞吐量波动巨⼤，完全不正常。

现在我们需要去观察⼀下服务器了
mpstat -P ALL 1 先看⼀下cpu的运⾏情况*
可以发现cpu的利⽤率呈现⼀种阶梯式递增的趋势，但是负载却不⾼，说明cpu运⾏的问题不⼤
jstat -gcutil 1 1000观察⼀下内存gc的情况
⽼年代内存空间不⾜了，所以导致新⽣代的对象进不来，频繁fullgc，fullgc的时间⼜会很长，所以吞吐量⼀直上不去检查jvm的内存空间配置
堆区总共只有1g的内存，⼏乎全部分给了新⽣代，导致⽼年代只有5M的可怜空间
修改内存配置
现在来修改⼀下内存参数，再加⼊⼀个并⾏回收的机制
再次运⾏脚本，观察TPS和gc频率
这次运⾏，fullgc的频率变得很低了，⽽且吞吐量也⽐较平稳，没有什么⼤的波动。

但是运⾏到⼀分半钟的时候，吞吐量出现了塌⽅式的下降，同时出现了异常。

观察异常⽇志，发现超过了tomcat最⼤连接数了
**修改tomcat连接数配置，再次运⾏脚本
这次不像刚刚那要⼤⾯积报错了，但是依然有⼀些异常出现。

有⼀部分是超时，还有⼀部分是 Software caused connection abort: recv failed 调整⼀下请求的连接⽅式，使⽤java模式，并保持长连接，再观察运⾏结果
这次⼀个报错的都没有了！。

2012年9月第27期科技视界SCIENCE &TECHNOLOGY VISION 科技视界Science &Technology VisionDCS (Distributed Control System)集散控制系统,是上世纪70年代国外推出的自动化控制系统,通常称为DCS,其控制系统的功能是由不同的设备来完成的,当某个设备出现故障时,对整个系统影响降到最低。

TPS 系统,是美国Honeywell 公司的一个先进的DCS 产品,是将整个工厂商业信息系统与生产过程控制系统统一在一个平台上的DCS 自动化控制系统。

可与管理计算机连接,进行远程高级控制和管理。

目前,我公司在用的DCS 系统全部为HONEYWELL 公司的TPS 系统。

1TPS 系统节点及功能介绍HPM:高性能过程处理器,用于扫描和控制TPS 系统过程数据。

NIM:网络接口模件,提供LCN 访问UCN 的接口,转换LCN 和UCN 的通讯技术和协议。

HM:历史模件,文件服务器,支持LCN 网络的系统活动、历史数据存储。

系统事件用于系统性能的观测、调整和故障排除;过程历史数据用于生产过程监控。

GUS:全局用户操作站,TPS 系统的人机界面,继承US 的全部功能,基于Windows NT4.0平台(为NTFS 分区)的Na⁃tive Windows 窗口使用。

控制网络包括局域控制网络LCN 和万能控制网络UCN,LCN 网实现集中管理,UCN 网实现过程功能,与HPM、LM、SM、PLC 等相连,实现各种控制功能。

2系统常见故障的分析研究常见故障有四大类:2.1通讯故障LCN 缆通讯故障;UCN 缆通讯故障;I/0LINK 电缆通讯故障;GUS 站与系统间的通讯故障。

产生故障的原因:设备损坏;电缆各种接头松动或脱开(常见故障);外来电磁信号的干扰(LCN 接地不好,经常出现故障)。

处理问题的措施:更换设备;重新将电缆进行连接,并用专用工具进行紧固;做好接地,满足系统的要求。

一、Error -27727: Step download timeout (120 seconds)has expired whendownloading resource(s). Set the “Resource Page Timeout is aWarning” Run-Time Setting to Yes/No to have this message as awarning/error, respectively处理方法：Run-Time Setting ------ Internet Protocol ------ Preferences------Option ------ Step download timeout(sec)改为32000A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大或多二、错误现象：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"Runtime Setting">"Internet Protocol：Preferences">"Advanced"区域中设置一个"winlnet replay instead of sockets"选项，再回放是否成功。

三、Action.c(7): Error -27791: Server “192.168.1.77″ has shut down the connection prematurely解决方案如下：1、应用服务器死掉。

1.性能测试常见失败现象性能测试上手难度比较高，是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科，掌握一门性能测试工具对于性能测试来说只是万里长征的第一步，没有一定的需求、开发和运维专业能力，往往会吃一些苦头。

很多项目性能测试结果往往很好，到了线上，还是会出现相关的性能问题，导致整个项目团队狼狈不堪，整个公司手忙脚乱。

引发不必要的损失。

这个是因为性能测试的方案或者思路不对引起，或者是测试执行过程中出了问题，此类现象归结为失败的性能测试，那么性能测试失败的原因有哪些呢？我们做个简单的分类。

1)无法正确的评估系统性能需求对性能测试进行需求分析，通常情况下我们很多功能测试人员会直接依赖需求人员或者项目经理的口述或者有缺陷的文档。

实际上，大多数情况下我们需要自己来引导相关的运维人员和需求人员给出具体的需求数据，并对这些数据进行二次分析，得出我们真实的性能需求。

对于初次上线的系统，我们需要用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提，利用性能估算法推算。

得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

对于已经上线的系统，我们可以通过运维人员获取TPS和时间的比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等，直接精确得出目前的系统的用户行为和业务数据关系，进而得出我们需要的性能需求。

现实的性能测试过程中，测试人员往往只是简单的对某个功能点进行精粗爆的压测试，甚至只压测试了登录接口，就用来评估整个系统的性能，怎么可能不出问题。

2)场景设计不合理充足的需求调研与分析之后，我们要在测试场景中尽可能真实地复原系统负载。

通过需要我们要决定哪些功能要参与性能执行，如何参与？这就是用例设计。

如何有效地组织测试用例就是场景要做的事，按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。

看似简单，实际操作起来还是比较麻烦的。

3)测试结果确认不到位在整个性能测试过程中，需要对每个系统节点都做对应的监控（不需要都很细，但一定要有），根据具体的网络拓朴，布置对应的监控。

一、Error -27727: Step download timeout (120 seconds)has expired whendownloading resource(s). Set the “Resource Page Timeout is aWarning” Run-Time Setting to Yes/No to have this message as awarning/error, respectively处理方法：Run-Time Setting ------ Internet Protocol ------ Preferences------Option ------ Step download timeout(sec)改为32000A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大或多二、错误现象：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"Runtime Setting">"Internet Protocol：Preferences">"Advanced"区域中设置一个"winlnet replay instead of sockets"选项，再回放是否成功。

三、Action.c(7): Error -27791: Server “192.168.1.77″ has shut down the connection prematurely解决方案如下：1、应用服务器死掉。