WEB性能测试与性能调优总结

1、前段时间，我们测试团队对新开发的一个数据分析系统进行性能测试与优化工作，期间遇到不少问题，并分析解决问题。系统从开始的50用户并发都不满足，优化到最终可以支持500以上并发，性能提升至少10倍以上，感觉很有成就感。在此，把整个经历过程给大家分享一下，文档是对自己这次性能测试进行一次总结。经过一个多月的性能测试，收获还是很大的，当然，由于自己经验方面不足，定位时间花费比较长，效率有些低。因此，写了这篇总结文档，分享下，大家一起进步，也希望对更多的测试人员在性能测试上有所帮助。一、准备：局域网搭建测试环境，系统主要模块，SSO登陆、数据报表页面查看、地图展示指标数据、大数据分析与结果报表展示。系统

2、主要是J2EE、后台数据库使用Oracle与hadoop。目标是测试该系统能否支持500用户同时并发，每个页面或局部刷新响应时间在2秒左右，且长时间运行稳定，也是对系统性能的一次摸底，找出性能瓶颈并优化使用浏览器代理方式，输入首页地址 HYPERLINK http:/xxxx http:/xxxx由于我们有SSO登陆，因此跳到登陆页面，输入用户名与密码。然后进入首页，首页有地图，有报表，类似下图：三、生成脚本通过“录制快照”来查看页面HTTP请求，了解我们系统的页面结构，页面时间，即正常浏览器点击到页面显示的时间，每个HTTP的时间与内容长度。这点也是挺重要的，开始对工具不熟，录制后调通脚本就

3、直接测试，结果发现测试结果有成功有失败，测试结果报告提示脚本时间比录制大，但不知道怎么分析；另外测试发现有些请求时间很大，已经超过10几秒。然后，测试过程中多次请教了工具的支持人员后，对工具有所了解，也是一些性能测试经验知识。TPS(TransactionPerSecond)即事务，事务是很重要的。我们测试的其中一个脚本录制的页面有2个页面，一个ajax局部刷新请求，性能测试要从用户的角度来看，即每个页面完成需要在用户可以忍受的时间内，网上说一般是2秒内认为正常，5秒内有点慢但还可以接受；ajax局部刷新也要在合理的时间。因此，在支持人员的指导下，为脚本配置了3个事务,2个页面分别事务,一个叫

4、login、一个叫main,然后也对ajax请求配置事务report；这样通过工具的统计信息，就可以单独分析login、main与report3个事务的成功与失败，事务响应时间是否合理，在合理范围内则表示测试通过，如果响应时间大则需要考虑是否合理。1、录制快照配置了3个事务后，通过录制快照来分析事务的情况4斫靶呻.色=题Z昨皿Lq(SS：l0ffl4IMS鼻滋-wekit!ao)e：ifta海刖事询卫出：所环mB*ai可it眸在料应-方科斬npfrwii计UELdrLfl0a0wFnzIfl锚1呂FaanfhFx订打皆inrtlm5Ntj叮却訂(41-HllFi期ImL扫嚨g口舛infjsii

5、fo/l阮芦p-Tif色i阕IIEQ-tiniiiQirr-B.&.jiCS-HTTEa期ja沁tfti&Se=Ti!3*pirjiiJfirifMpi=ini.-3L3E1jxCET-HTTTl200ji412345IB3阳E/钿屮屮Ubrfp冋CET-HTTTl2aaEBHITK491B37/rihM+L1HrFClni#il旳:ECET-HTITlanBIH-!49IB3IDmi;CET-HTTTl200dCECM245IB3II払甲屮中2中匈prq;CET-HTTTlXMEfl叶l-U491B3CET-HTTTlBIH-n:49IB3113骑护事吾J.r.aaMK畔衿Inaa035rK

6、THnrl2ME逛忖3M44KD0-IE-CET-HTTTlM4l-U4QCC0B11CETXU137斗SCDC绑BfCETS2Vlfi2LL4KMSIIS加irgm皿畑r吃CETJO2Vlfi41.1.4K1I班：D/idlyc.；jieheeI曲E-nrWM：EC9EDU-HA0CETM2EfakW34G4SC12-irElrxksi询rrlnCET2M血LnLT7JKUD5可以看到每个事务包括了那些请求，该事务录制时花了多长时间，这个时间是测试结果报告里的录制参照值，测试结果报告的事务时间跟这个值对比就知道是否时间合理。同时，可以看到脚本包括多少个HTTP请求，后台请求有多少个、图片有多

7、少个，主要时间花费在哪里；每个事务包括多少个HTTP请求，多少个服务器，哪个服务器占用时间比较大。申E飞、-IIo!：e-：.-fr：ic-ite-iOXMM.(L；l0li?直D.乂比.CM*hW.$0014.CN1()QCMl.BDfiO(1)事奇列羔所有喧认迅二、讪口Orepra-t檢廡!UP衣可能存在生个页面!建谡対毎个页面逵一t葫卜方損后面测试时，发现很多问题，也是通过录制快照来分析页面结构，发现请求太多、有些Q重复(96)请求没有进行缓存(快照的重复有96个)、图片与JS请求太多，后面进行了合并减少了http请求，也提高了成功率和事务时间。另外，通过快照里的“并发时间图”来查看每个

8、事务浏览器是怎么并发的，是串行一个一个发送HTTP请求，还是并行多个发送HTTP请求。这个也非常重要，因为，开始测试时，没有选择模拟浏览器并发，测试出来的事务时间非常大，有的达到几十秒，比正常浏览器点击页面时间2，3秒时间大很多。后来咨询了工具的支持人员，才知道有并发跟串行的说法，下图可以看到，浏览器基本是并发执行请求的，后来网上了解了浏览器并发原理，还有通过浏览器的F12的网络分析也发现确实是同时并发HTTP请求的。听工具支持人员说，好像现在其他测试工具是不支持一个虚拟用户并发HTTP请求的，以前用loadrunner也没去研究，不过好像确实测试的时间总比正常浏览器访问要大。这个后面再确认，

9、如果真是这样的话，那确实工具这点挺好的；因为每个用户的并发与浏览器一样，对服务器的压力就基本类似，测试的结果响应时间也真实反映每个用户的情况，如果是串行的话，时间大了也不知道怎么分析。2、脚本调试脚本录制后，开始测试前需要对脚本进行调试。回放、关联、参数化、验证脚本；通过工具提供的帮助知道文档和支持人员的交流，脚本顺利调试通过，也通过后台数据库和工具的验证页面功能查看，脚本通过。OK,下面开始性能测试和结果分析、调优了。第一阶段测试开始没配置login、main与report3个事务，也没配置模拟浏览器并发，调试通过后就直接跑，可能是自己对性能测试经验不足，不知道配置事务这么重要。同时并发50

10、个用户，看下怎样结果测试多次的结果，有时都成功，有时存在2，3个用户失败，但脚本执行时间居然80%以上达到将近50秒，2个页面一个ajax局部刷新，正常使用浏览器时，也才几秒，应该不可能达到这么大啊。测试时，自己使用浏览器访问页面，有时地图加载失败，有时成功，页面出来也比平常慢。懵了，怎么定位呢，经验严重不足。先从工具提示与统计来分析，再加上请教了工具的支持人员，也学到了一些分析方法。工具汇总报告如下：自定事务时闻过长事箱一檢嗥页面无一牛我期糰血事掘时rsi应当属足“旷旷屮舸畀鈕讨日护篦孚氐関户栋豔葺c削高、SMfsitaputtara.ntw密、涨u/o他基萄縣掰词陆特他响楼时间協如舉不Sc

11、FijSttfflfi因.雨：乐煤1加11飜因可远在血理応启flT+硏阳户详轴轄息加4倚用户的SfimTflt处恳审券的时iHlrra出来遊打并析冷从舌哇:tittw业imr?js欢导测i底嗣减下ifi列犁争努屋光时闾比录制的时闸犬谢的常BL*3Miffl*SWlE自己握按自貝业券舟?tut时丽）ift大M7531441TC卩连楼R匕土丄F眦十瓷|iiC?ir卩吊飓孑區*S可irtWTC?世乂汕I；UTCPitAJW|吐口.iiV-A-i-tlA:JRMmsrafeAU伶-irttiflJLIfc好濡、已碍、蘇打加?觀I彷导M.丁：丁三左塩#注丄刃问的Z%J仞rre三逾推手ffieiBSefr

12、ttSKi.4S查看“用户详情”的“用户与事务统计”如下：可以发现80%用户总时间达到47秒左右，但录制时使用浏览器整个时间才7820毫秒，即录制值，相差非常大。查看“脚本请求统计”分析HTTP请求，如下图:查看每个HTTP请求的统计信息，最大响应时间、90%、80%时间。这里支持点击列排序即可以找出时间最大的HTTP请求有哪些。IJSi!1rpyEKTi.ijlba.pifLtrinwULl|o|44331Z5H!131Q51di转斤畔山廿前专躍jlpn.p!.a.e-jw.j0.l:砂EEfid固BBI日H*WMI*用尸裤船語MHWtoT，小略汙HETr.CTObftJirl4SI_彌询|

13、iLlR的|丄田|丄1传尺方古石Ittfci.MB;BfJiff比疋x栅曾fti-114千均me录細0wi山求点击“详细分析”F谨塑旗查看更细分的统计，可以按域名、HTTP类型等分析其中，访问google有两个请求时间比较长，另外，界面下面给出域名占总时间比例还是比较大，因此可以确认访问google是一个瓶颈点，工具用到google地图。在“脚本请求统计”界面的滚动条拉下来可以看到，有哪些请求失败，失败原因是什么，下面是50用户都成功时的统计，显示TCP建立时间超过3秒，表示这些请求响应时间太大，应该是TCP建立时间长导致。如果这里有其他失败，也可以看到统计，很方便分析。根据根据分析，初步确认

14、google的请求时间比较大，那为什么会大呢，需要定位找原因并解决，由于自己在性能测试经验上欠缺，问了工具的客服人员，说可能是网络原因，汇总报告里也提示建立TCP时间长可能是网络原因。OK,咨询我们的网络人员，网络人员给了个Ping如下：正在Ping HYPERLINK 0具有32字节的数据:来自0的回复：字节=32时间=542ms来自0的回复：字节=32时间=420ms来自0的回复：字节=32时间=511ms来自0的回复：字节=32时间=480ms发现测试环境到google服务器的网络时延比较大，达到500多毫米。另外，分析访问SSO服务器的HTTP也时间也比其他HTTP长，但比google

15、时间要小一些。网络人员给出的解释是，因为公司网络到SSO服务器和到google服务器的带宽比较小，而且是办公网络，当前是办公时间，大家都在使用网络oSSO服务器网络原因解决办法比较容易，让网络人员对测试环境的网络做一些配置；而google响应慢与开发交流，先不理，后面可能会专门开发个缓存代理，不用每次都去google访问。所以，测试脚本中把google的HTTP请求删除掉，目前测试我们自己服务器，先不管google。五、第二阶段测试为脚本配置了3个事务，目的是从事务的响应时间来分析页面或局部刷新的时间是否合理；2个页面分别事务，一个叫login、一个叫main,然后也对ajax请求配置事务re

16、port；前面通过修改网络和删除google地图相关HTTP请求，响应时间提升了10多秒。但还是40秒左右，离我们目标每个页面2-5秒范围相差很大。测试过程在同事电脑上使用浏览器访问页面，也还是很慢，证明系统可能有瓶颈。怎么优化呢，第二阶段与第三阶段性能测试耗时最长的优化就是这阶段，也是最具有挑战性的阶段。发现了很多问题，通过优化，性能提升很大。网上查资料、看论坛，大概意思就可能是网络原因、数据库原因、CPU、内存的；OK，在测试时添加服务器监控，在工具controller界面添加服务器、数据库内存与CPU监控，配置添加monitor监控器设置工具E运行削帮瓯H)G日-林砒理器Alt4-A蛀f

17、熠器Ctrl+AltfM媒匍谨器Ctrl+Alttl國直Ctrl+Alt4-ESeripterAnalysis%网存可用空间*內存已用空间%內存已用空间交械区读取的总更顼*读取的忌可放隰写廐的总页顼*写九的总可埶飜交换区可用空间$交扭区可用空间交携区已用空间ftCPU占用聿$用户占用奉%至貌占用聿$由断莖备注%CFir占用奉CFHTot-al内存可用空间MenoryTotal运行结果发现tomcat的CPU与内存很低，但数据库CPU在查询时有点彪升，因为页面涉及到地图数据、报表数据都需要访问数据库。通过工具详情分析里的HTTP后台动态类型分析，部分HTTP请求时间比较大与开发交流，开发团队给出

18、了解决方案，增加redis缓存，把一些常用不改变的数据，如地图边界、常用报表在tomcat启动时就加载到缓存，另外，把数据库查询结果保存到缓存，如果是一样的查询语句，则直接从缓存读取，减少到数据库查询，提高效率，终于把后台数据库查询的HTTP请求时间降下来。六、第三阶段测试1、脚本修改为模拟浏览器并发上面通过redis缓存解决了后台数据库并发性能差的问题，响应时间得到大幅下降，总的响应从40多秒时间降到20秒左右，3个事务响应时间分别在6，9，5左右。多次测试仍然还是20秒，但测试过程使用浏览器访问页面都正常，页面出来时间也大概1，2秒时间。经验不行，不懂怎么办了。此次测试是摸底系统是否可以支

19、持500用户数并发，即页面访问都成功、而且每个页面或局部刷新响应时间在2-5秒范围内；现在每个HTTP请求，都比较合理，与录制值比较相差不大，但每个事务时间在8秒左右，总时间20秒左右，以为系统无法支持500用户；咨询工具支持人员，原来脚本没配置“模拟浏览器并发”，然后启用“模拟浏览器并发”终于把时间降下来，降到10秒左右，login事务对应页面、main事务对应页面，局部刷新事务report的响应时间都在3秒左右，正常范围，50个用户通过。为什么要“模拟浏览器并发”，问了工具的支持人员，原理大概是我们使用浏览器访问页面时是并发的，可以通过浏览器的F12调试工具的网络查看页面的HTTP请求;网

20、上搜索了下，好像一个域名可以同时并发6个请求，那我们系统有多个域名，至少6个并发以上；如果没有配置“模拟浏览器并发”工具执行脚本时是串行一个一个HTTP执行，那当然比正常浏览器慢。另外，工具串行500个并发比浏览器500个并发压力不是一个量级，可能相差好几倍。如252辆车（252个HTTP请求）要到达目的的，一个是一车道（串行）还堵车（阻塞），一个是6车道（并行），时间差别很大，对服务器压力也差别大。2、逐步提高并发用户从并发50用户数，慢慢提升到并发100、150、200、250、300、400、500用户数。当运行到150时，出现脚本执行时间变大，最小有10秒左右，但大部分在15秒，也出现

21、TCP建立时间超过3秒，类似上面开始测试时，google的HTTP请求响应时间大。但自己在并发测试时使用浏览器访问，页面显示正常，可能比平时稍微慢点点，但也没那么明显，因此感觉是工具问题。工具报告提示：TCP琲接祥吐址曲陶卡確如crnn.囚韜可ict建丘时间唯过乩nt除示恒人可吐存?Isnr包去養羞啟i*检査址駅毎器Mh砂帆9MK节导政的-MF三枚握手建业舸圖車北世=調据KPFfiffl+iS立AJ间禺过益口挣的曲爺恋查看“脚本请求统计”分析HTTP请求，没有特定HTTP比较慢，而是整体响应时间都大了，有一些小的CSS文件也比较慢，如下图：也可以看到大文件的“首个接收分片”比较快，但后面的剩余

22、数据接收时间比50用户时要大，如下图苦埠方吿TCfL暉Lel3.Lro|150IM3E|vq|5M1在百度里搜索，还有咨询了支持人员，发现这种现象一般是网络延时，带宽不足或CPU太大问题。根据工具提示的汇总报告，也表示可能是CPU高、网络拥塞；查看服务器CPU，才8%CPU,那应该是网络问题，但我现在是在局域网里面，网络很好，而且自己使用浏览器访问正常感觉不可能是网络问题。后面注意到汇总报告有一个吞吐量告警：吞吐量/秒（1Mbps=128KB）TWIbpr*m=8T5OKE長应用层倆吐比底恳TCTF至夕占上荷ttE千啦码可帘吿警，輙色到轴隋可靛导蝕TW立朱败、It跑删国Hfc、悬*5以在皿曰拧

23、恶rtg辜单退銀出起a-SWMES.卄甌删帝?顾鳏时间点、-t-ift.彌査理孙器”屋顽毎，dmr那齡o紬谡襪湖查看了工具所在机器的网卡，是100Mbit网卡，服务器是1000Mbit网卡，即瓶颈在工具所在电脑的网卡。50用户总吞吐量为56750KB（约56MB）,即每个用户吞吐量大约1.1MB,对服务器每秒的压力是56MB/10秒=5.6MB，换算成比特，就是44Mbit/秒，那么150用户就大约130Mbit，超过网卡极限。咨询了工具支持人员，他告诉我解决办法有两个，一个是采用多个agent执行器分布式执行，这样可以避免网卡瓶颈；另一个，他看了脚本录制快照后，发现我们脚本HTTP请求太多，

24、重复也太多，给我建议需要优化页面，可以采用缓存，减少HTTP个数、压缩文件、合并文件（图片、CSS、JS）。因此在网上找找这方面的资料，在网上看了很多文档：例如 HYPERLINK /article/20140118/535246.shtml /article/20140118/535246.shtml从工具“录制快照”看到，一个脚本里面有96个重复HTTP请求，总共有252请求重复里面点击URL排序可以看到有些CSS、图片重复多次，如下:H应码类fl!医舉JD/iDLdtT/csE/bm.csserr2WC55J5T5T|jQ1仏.小此匕CSLstrECOCEE15T67!5/itidtic

25、/cESLib-i-sic.ceeJIT2WCS53113T/iDLdjU/CE.S./b-uic.CSETWCEE闵】：12jinJ占*r.丿eEE/Lacee応SCOflEE4Q2SQ3fiDLd4KFcs7L4加Iat.essstraoCEEQKB-!EE.i1indax/l/milTorJIT2td显片3404:典findjU畑御玄心苗丄.PTeSETW3ILH-J3E.i1iadax.!1arikir-aiZ-nsajoifGET2D03Uii54/：1鈕小4阿/58JTi；割2C0an3*01!G5.i1iridax.11miiK-fTOrjETEDO3U4i69GETKCam19

26、1.i1iadax.!1arikir-aiZ-nsajoifGET2D03Ui:93riadtri1dr時m/e話】JIT2W駅3*0*11.i1iridax.11miiK-fi/icanxB.priL.pnp：GETEDO9DH33:翟yiddflci1t.pnc5IT2W90319jiadjui1arikE-iaJlvKv.cL.Ctf.putITEDOq卿：51点口如丿讪時裁101|师pnfJIT2WCSS、JS、图片多次请求，而且都返回一样的内容，即一个文件请求了多长，如果使用缓存，则可以减少CSS、图片的下载。另外，按字节大小进行排序，可以看到一个地图相关的HTTP请求内容长度达到近

27、340KB,内容格式为json，而且没有压缩；js文件达到455KB，也没压缩。从测试结果看到，该请求响应时间也比较大；平尸丁:afh-，“、r.nDT*J-3E*L扭嗨胛本砸沁呻斑，斟刪呵面發空竺方相婶与aIJKL方注戋型商ftMT-北5的T53l/LndcKi1GET1启台动宏3T39|把当前问题告诉开发负责人，开发负责人也意识到这些会影响性能，整改页面结构与代码。3、整改页面结构经过整改，为tomcat增加了缓存、压缩JS、后台代码压缩json、合并很多小文件。重新录制页面脚本，发现HTTP请求总数从252减少到104个，减少了近150个HTTP请求；JS与json压缩率也非常高，340

28、KB的json数据，经过压缩后，只占约8K，压缩比惊人。再次测试，50个用户由之前的10秒左右，降到近5秒多，3个事务的时间也都在1-2秒左右；当并发150个用户脚本执行时间也在6秒左右；性能提升还是比较大的。为防止测试工具的执行器Agent瓶颈，后面测试使用了两个执行代理器local与linux分布式测试。萨kylinPETController-edit*|文件(F)却S)工Am运行贰帮助(H)町鄆囲宣用户诺時體華I-斟範NUlZj丄疋4碎lirnutsk進箜理留植型矚程室煙军r谨率/理1总托户数:co点：沁S始央行辛尸站运連率-?nri立即运行所勻住戸运-亍芫悟止运行L衣则传匕再次递增用户

29、200个，也是近6秒多，3个事务的时间也都在2秒左右，还算正常；递增到500个时，脚本响应时间明显加大，有部分用户时间已经达到12秒，更有达到15秒以上，也出现用户失败，出现部分JS或图片访问失败，失败日志如下：oxi：3：aLoci!srrcrhopetluq-60sbutiQrvorcLozatcjtin=&DD2ns.thtip:/000:13:431O：41trrcrhopeime=60sbu.1servarclosetcptine=6003nsj.thtip：/1000:13:49errwhup亡11ms=60sbutaerrercLqsctcjLlinie=&DD4nshttp：0

30、00:13:43localerrorhopetine=EOslbutserverclosetertine=6003nslathttp:/om：i3：4alocilirrorhopeline=6Ckbutarvarclosatrptina二5999nsithtip:/0：3：-53Loci!srrorhopetLmQ-60sbutiQrraircLoeqteptints6000ns.thtip:/000:13:43!：iltrrcrLh&peime=60sbutzerv-trcloseteptine=&0Xnsja.thttp：/1000:19:49Localerrorh.Dpeiiine=6O

31、3butserverclozetcjiI.lime=&0D1nsaAhi.ip：/hopetine=492e!tutservercloseteptime=GXGnsathtti：?JOKI：13:4aLotalirrorhopetine-238ebuteArverclosbteptiraa-A002ncb.tlittp：oxi：3：aLocLsrrcrhppe：tLinG=60sbutsflrvsrcLoetc;tin-s=&0Z1nshtip:/000:13:48lo：41errorLhopeime=60sbutservercloseteptine=6024nsj.thtip:/日志大概意思

32、是服务器在发送HTTP请求后的6秒左右关闭了TCP连接，所以没收到HTTP请求的响应，导致用户失败。测试时使用浏览器访问，确实页面出来慢了很多，有时也页面出不来，应该是服务器问题。工具给出的汇总报告有如下告警：眼务赛主动关闭TCP3Wf：沁I和i潮日苗-族*#析出观1L-.liWIJH祸感ll耐是衲J昏汗-咨询支持人员，从经验看应该是CPU太大或者线程池、连接池不够，导致HTTP请求无法处理，tomcat服务器主动关闭TCP。看了服务器的CPU，服务器CPU有8核，CPU只占20%左右，应该不是CPU原因；但查看数据库所在的CPU比较高。奇怪呢，数据库高应该只影响访问数据库的HTTP请求才对，

33、怎么连图片或JS也失败呢。最后，我们开发团队一位牛人，通过java的dump日志，发现是线程阻塞了，数据库访问太大，导致线程都阻塞在等数据库的响应，无法再处理其他HTTP请求，包括图片与JS。解决办法，提高数据库连接池个数，提高tomcat线程池大小，同时配置阻塞为非阻塞NI0：4、调整线程池、数据库连接池配置完后再次500个并发用户多次测试，总的脚本响应时间与3个事务响应时间都在正常范围，终于支持500并发用户数了。当然，由于我们脚本录制时请求都没包括缓存头域，正常用户访问时，部分图片或JS、CSS请求浏览器已经缓存了，所以正常的500用户并发对服务器的压力应该比脚步500并发要小些，因为部

34、分图片或JS、CSS不需要再请求。到此，已经可以支持500用户了，后面还需要进行稳定性长时间测试。七、第四阶段稳定性测试一个用户完成脚步大概7秒时间，因此每秒启动70个用户，保证后面近500用户同时在线长时间测试稳定性也是很重要，此次测试期间发生过redis缓存挂了、tomcat内存溢出、1、redis缓存挂了长时间运行近50分钟后，发现后面的用户都失败了。从测试统计结果与日志提示发现失败原因是服务器返回500响应，失败的HTTP请求为访问数据库的HTTP请求。此时，使用浏览器访问系统，页面也出不来，无法正常显示。后来，查询服务器发现redis进程不存在，多次测试都这样，开发定位说是内存问题，

35、同时也暴露了redis单点问题，架构上需要考虑主备。2、几小时后失败用户数递增Redis内存问题解决后，在长时间运行4个多小时，发现失败用户数占约5%点击“用户详情”分析结果如下：失败类型基本是跟TCP连接相关，也存在接收超时查看“失败用户图”，失败用户基本在4小时（14000秒）后uioaajioo曲皿斗应m甸rioo加oo即血卵讪1曲3lijooujoo13血：心iboE4-jCCb.i42iXj00D+/mo3W/WMMFJ3DDifiCh/JOUhSiv/raIMUJDUIW/W艸Irr靈i12U/JWIMFjCmRCLOW20/jDDmit|g1昨iw-w-即酣胆b1费m；k：5KM

36、OTC03巾叫rm失败类型为“TCP建立失败”“服务器关闭TCP导致无响应”也基本是发生在4小时后n:rB.Odtftl1413V*I2MJIM*IW3IMMimn札in.-rwwiin.?nn11.?12.唤12.i?.nm17.H.rwwiH.1?.：那么运行到4小时后发生什么情况导致失败用户数递增呢查看了在线数，发现0秒到3小时50分时比较平稳，大概在740个用户，但到了4小时的时候，在线用户数飙升到3000多，对系统造成的压力远大于正常，所以脚本失败与响应时间都增大。放大图表，可以看到3小时之后基本都在3000多在线用户数运行多次长时间运行，必会出现这种情况，后面一位开发牛人分析发现是

37、阻塞与jvmfullgc垃圾回收频繁导致。检查了数据库SQL语句性能，发现有些没添加主键，日期格式是字符串格式，导致效率差；部分SQL语句通过SQL执行计划分析发现筛选条件不合理。从而导致脚本执行时间长，然后又由于新用户一直在递增，所以就出现老用户还没结束新用户又增加导致在线用户数达到3000多。解决思路，系统部署环境由只有一个tomcat改为Ngnix+tomcat，把静态的CSS、JS、图片、HTML放到Ngnix,Ngnix启用缓存;把动态的HTTP交互交给tomcat处理，这样减轻了tomcat的压力与TCP连接。数据库增加主键、修改SQL语句提高查询效率。3、tomcat也挂了优化SQL语句和改