性能调优总结

深圳割接性能调优总结BSS测试部：邹家勇HSC从一开始对订购关系与三户资料同步接口进行压测时，不能满足性要求到最后性能压测结果达到要求的10倍性能以上，经过了以下几个关键的优化步骤。调优过程：在压测时首先要排除的是高消耗SQL（经过AWR报告分析后HSC没有出现高消耗SQL）本次SZ割接压测经过以下几个关键点的调优：1)脚本参数调优（数据已存在，字段值太长错误较多调节脚本参数模式及参数长度）2)JDBC配置调优(JDBC使用率100%，连接数调成100后，极限测试时使用在80个连接左右）3)WAS配置调优（主要是webcontainer调成200，极限测试时使用达到200，但主机CPU资源消耗在50%以上，且TPS也超过指标10来倍，不再增加配置）4)IHS配置调优（主要是http.conf文件参数调整）5)linux系统调优（主要是网络参数调整，及openfile调整）6)Systemout日志中不打印应用日志（减少不必要的磁盘IO消耗）。下面逐一分解每个关键调优时出现的问题及定位脚本参数调优举例说明：在测试过程中，通过查看WAS日志，报大量的主键冲突，经查明后，发现是发送的报文中写表的主键字段值重复导致，经过对主键字段的重新参数化后，不再出现主键冲突，大量主键冲突也不符合平台业务交易场景！（原来红色部分值采用一段随机值或序列发现还有重复的值出现（测试工具本身问题））订购关系脚本Action(){lr_think_time(3);lr_start_transaction(订购关系同步_SubProductSyn_request);soap_request(StepName=SOAPRequest,URL=http://{IP}:{port}/Nodehsc/services/HscService?wsdl,SOAPEnvelope=S:Envelopexmlns:S=\:BodySubProductSynRequestxmlns=\{servnumber}/MsisdnAreaNo{region}/AreaNoCommandIdSubProductSyn/CommandIdVersion1.0/VersionTransIDSZ{transid2}{transid1}{transid}/TransIDLogID0/LogIDSeqID0/SeqIDMaxSeqId1/MaxSeqIdRecdate{date}/RecdateInterFromEDFS-----/InterFromOperIDauto/OperID/MessageHeaderMessageBodyTradeTypeChangeProduct/TradeTypeOrderID{region}99{OrderID}/OrderIDSubsProductListorderlineid{region}99{OrderID}/orderlineidSubProductOperTypeI/OperTypeSubsprodid{region}99{subsprodid1}{subsprodid}/SubsprodidIsMainProd0/IsMainProdSubsid{region}99{subsid}/SubsidProdidprod.{prodid1}{prodid2}/ProdidPackageid/PackageidPackageprodid/PackageprodidProductkind0/ProductkindBillId{BillId}/BillIdBasePrice0.0/BasePriceFee0.0/FeeStartDate{date}/StartDateEndDate20991231235959/EndDateGrpSubsid{subsprodid}/GrpSubsidStatus1/StatusDonortype/DonortypeDonorsubsid/DonorsubsidDonorsubsprodid/DonorsubsprodidSubProdAttrListSubProdAttrOptypeI/OptypeSubsid{region}99{subsid}/SubsidServiceidPtest{servicesid}/ServiceidAttridttPtest{servicesid}/AttridAttrValue195{servnumber}/AttrValueSTARTDATE{date}/STARTDATEENDDATE20991231235959/ENDDATE/SubProdAttr/SubProdAttrList/SubProduct/SubsProductListSubServiceListSubServiceOperTypeI/OperTypeSubsid{region}99{subsid}/SubsidServiceidPtest{servicesid}/ServiceidProdidprod.{prodid1}{prodid2}/ProdidSubsProdOid{region}99{subsprodid}/SubsProdOidServiceStatus1/ServiceStatusStartDate{date}/StartDateEndDate20991231235959/EndDateservType/servTypeSubServType/SubServTypeSubsServResoureListSubsServResoureResClass{ResClass}/ResClassOptypeI/OptypeSubsProdOid{region}99{subsprodid}/SubsProdOidResType50/ResTypeResid521/ResidStartDate{date}/StartDateEndDate20120908030405/EndDate/SubsServResoure/SubsServResoureList/SubService/SubServiceList/MessageBody/RequestMessage/SubProductSynRequest/S:Body/S:Envelope,SOAPAction=SubProductSyn,ResponseParam=response,Snapshot=t1370244229.inf,LAST);lr_end_transaction(订购关系同步_SubProductSyn_request,LR_AUTO);web_find(web_finded,What=成功,RightOf=ResultDesc,LeftOf=/ResultDesc,LAST);return0;}调整如下：1．TransIDSZ{transid2Transid为写日志表主键（况下，几乎不会随机到相同的值2．Subsprodid{Subsprodid:为订购表主键subsprodid为5位随机值3．Subsid{region}99{subsid}/SubsidSubsid为服务表，与附加属性表主键值4．其它字段值尽量符合平时的业务请求字段值进行设置JDBC连接数配置调优在压测过程中发现TPS一直上不去过对主机资源的CPU,内存测试（从压测客户端FTP速度较快，能达到10多测试中通过控制台性能监控模块监控transid2}{transid1}{transid}/TransID（22位长度）：分成三段，每段取用6位随机值几乎不会随机到相同的值Subsprodid{region}99{subsprodid1}{subsprodid}/Subsprodid为订购表主键：分成三段region为序列值，subsprodid1为位随机值。Subsid{region}99{subsid}/Subsid与附加属性表主键值（14位），同样采用值两段其它字段值尽量符合平时的业务请求字段值进行设置连接数配置调优（配置同步已割接地市）一直上不去，并随着测试时间的加长，间断性出现超时现象内存，IO分析没有存在性能瓶颈，并同时对网络的传输速度进行FTP-get/put多个小文件及单个大文件到压测服务器主机多Mbps）网络也没有瓶颈。测试中通过控制台性能监控模块监控随机值，在大并发的情}/Subsprodid为6位随机值，同样采用值两段6位随机值间断性出现超时现象。通并同时对网络的传输速度进行多个小文件及单个大文件到压测服务器主机，发现传输从上图看到，JDBC：waitingTreadCount（等待连接数）达到80多个。同时JDBC:Poolsize一直保存在10。诊断为JDBC连接数过小导致。检查每WASserver的连接数后，发现最大是10，立马把每个server的JDBC最大连接改成了100并同步集群，清除场景跑出的压测数据后（还原数据库环境），再次进行调测，发现TPS在100笔以内波动据为10，发现TPS保持在（连接数最小连接，此项调节并同步到已割的地市潮洲，揭阳，肇庆，云浮调整后TPS：WAS配置调优（配置同步到已割接地市经过上面JDBC的调节，性能已经达到了上线的要求左右，内存使用在测试前与测试中波动非常小及得到性能极限值，继续加大并发进行测试根据这个错误代码，联想到通过压测过程中查看serverwebContrainner也是性能瓶颈笔以内波动且每隔6到8分钟会有一次较大的波动，再次调最小连接数保持在200笔左右，且相对较为平稳，此时性能值已经符合上线要求此项调节并同步到已割的地市（佛山，中山，珠海云浮，青远，韶关），省HSC）配置同步到已割接地市）性能已经达到了上线的要求，但经过分析主机资源消耗存使用在测试前与测试中波动非常小，IO也较小）为了使用主机资源能合理利用加大并发进行测试，在测试过程中出现有http:404联想到WASserver配置是否不合理。server的Webcontainner连接数使用一直都是也是性能瓶颈。再次调最小连接数此时性能值已经符合上线要求珠海，汕头，汕尾，但经过分析主机资源消耗（CPU在5%为了使用主机资源能合理利用，http:404错误。连接数使用一直都是100~98，看来分析过程：检查了IHS的access_log日志，发现的确有404的返回：10.252.17.58--[21/Jun/2013:12:10:27+0800]POST/Nodehsc/services/HscService?wsdlHTTP/1.140428910.252.17.58--[21/Jun/2013:12:24:39+0800]POST/Nodehsc/services/HscService?wsdlHTTP/1.140428910.252.17.58--[21/Jun/2013:12:25:00+0800]POST/Nodehsc/services/HscService?wsdlHTTP/1.140428910.252.17.58--[