金蝶BOS性能测试分析分享.doc

金蝶BOS性能测试分析流程 目录1.概述21.1.简介21.2.参考资料22.性能分析流程22.1.概述22.2.分析思路22.3.步骤结果输出32.4.分析流程33.分析工具43.1.概述43.2.工具分类介绍43.2.1.HttpWatch43.2.2.ThreadDump53.2.3.Jprofiler73.2.4.jca40173.2.5.ha40473.2.6.ga40173.2.7.jconsole73.2.8.TOP SQL14.总结114.1.BOS的Enum问题114.2.云平台发布元数据死锁111. 概述1.1. 简介最近通过BOS6.3版本的4-5月份集成测试与云平台的性能测试两个案例分析，发现性能测试只定位发现问题的工作方式不利于问题的快速处理，进而错过问题的最佳处理时机，给后续的发版带来很高的风险，4-5月份的集成测试只反馈CPU高消耗的现象与WEB的jprofile分析文档，因开发人员过忙与缺少实际环境而把问题一直耽搁着，这个问题本来在6月1号就发现了，结果到了7月5号迫不得已才组织人员协同分析定位问题，问题定位后也快速解决了问题；而云平台的性能测试我一直跟踪并协助定位性能问题，问题定位后，开发迅速修改代码，整个过程发现的几个重大性能问题都得到了快速的解决，通过对比这两个性能测试案例，得出只有快速定位问题才能高效的解决问题，只反馈问题现象，缺乏足够的依据，开发人员很难快速修复问题。为了在BOS性能测试过程中快速定位问题以及在调优测试中快速找到性能提升点，特意整理在分析性能问题过程中涉及到的一些工具与方法，以便快速解决问题，本文将从用例分析、问题现象、问题分析、问题定位、辅助工具等方面规范性能问题的分析过程以及工作过程中的输出文档。1.2. 参考资料2. 性能分析流程2.1. 概述处理任何问题都有一套方法，性能测试分析过程也一样，我们平常测试发现的问题只是问题的表现，我们要透过现象逐步分析到问题的本质，透过本质我们才能快速解决问题，下面我就按经验来整理一下性能问题的分析思路与通用流程。2.2. 分析思路我们通过一个倒金字塔模型来整理一个分析思路，由上至下逐步聚焦问题,测试过程中首先是会发现问题，发现性能问题后，我们第一步要确认是否是测试用例设计不当而导致的，如果不是我们就要用后续提到的各种工具与方法出具问题分析结果，根据分析数据推断出可能存在的代码可疑点，然后与开发一起如果修改问题。2.3. 步骤结果输出 步骤步骤名称步骤输出文档1资源瓶颈分析收集CPU、内存、IO、网络资源2用例分析提供用例设计文档3热点分析1. 如果是WEB先提供Httpwatch分析2. 如果是GUI则提供RPC日志3. 如果资源没啥消耗，资源又不消耗，可以通过分析服务端的RPC日志来分析JAVA调用堆栈以及SQL调用来分析问题4. 如果是数据库服务器的瓶颈则提供Top Sql以及相应的执行计划并给出分析结果5. 如果是应用服务的CPU消耗高则提供Jprofile快照文件与threaddump文件，并给出分析结果6. 如果是应用服务器出现死锁则提供threaddump文件跟dump文件的分析结果7. 如果是应用服务器的内存泄露则提供内存的dump文件，并给出泄露的可疑点8. 如果觉得应用服务器的GC有问题，则提供GC日志文件并提供对GC问题的分析4代码跟开发确认问题并记录引起问题的原因2.4. 分析流程下图整理一个在性能测试过程中发现性能问题而进行问题定位的分析流程，本流程里不涉及到硬件绝对瓶颈的问题，如磁盘空间不足，另外应用服务器跟数据库服务器的参数都按照产品配置说明进行了正确配置，本流程图只用来指导分析软件本身存在的问题。3. 分析工具3.1. 概述本章节对分析各类问题涉及到的工具进行介绍，在问题分析中，不同的问题都有对应的工具进行辅助分析，选择正确的工具有助于快速定位问题，从而提高问题的处理效率。3.2. 工具分类介绍一些将从IE、Java、数据库三方面对使用到的工具以及基本使用进行讲解，以此给在性能分析中提供参考3.2.1. HttpWatch. 工具使用只要打开HttpWatch，然后点击录制，访问IE后，所有的HTTP交互就被录制下来，. 分析思路通过是否使用catch来判断实际跟服务器起的交互次数，通过响应时间来判断哪个http请求消耗的时间较长，以此来初步判断存在问题的页面. 分析案例1. 问题大连中升项目3个强并发压力测试,发现响应时间比较长，应用服务器CPU消耗过高，能达到60%2. 分析通过httpWatch分析http交互过程，重点分析pseudocode.jsp页面,发现该页面每次都要向服务器提交提交60K左右的内容,从提交的内容看出，提交把一大片的HTML代码都提交到WEB SERVER了,而从下面的分析图中看到，一个实际的业务，其实业务本身性能很好，花了1.011秒，而实际pseudocode.jsp花了4.152秒，从这看出pseudocode.jsp性能很差劲,需要优化3.2.2. ThreadDump. 工具使用1. 通过调用EAS门户访问dump工具,访问端口号视具体情况而定，如下05:6912/easportal/tools/threaddump.jsp2. 在打开的界面中分析线程的数量以及线程的调用堆栈. 分析思路通过分析总线程的数量或某类线程的数量，如果出现的太多，而次数系统运行状况不好，则可以怀疑某类线程调用出现问题，通过线程的调用堆栈，可以推出哪些类的方法存在问题. 分析案例1. 问题金汉斯反馈最近打了几个补丁（有若干关联补丁）后，应用服务器CPU持续100%，系统功能整体非常慢，登录超过1分钟，单据提交10几分钟才能完成2. 分析连线看了一下，应用服务器内存消耗正常，排除GC引起的CPU消耗异常。查看threaddump，发现总是会有几十个活动的线程，虽然线程对应的业务方法各异，但都调用到动态扩展平台的方法，且堆栈大多停留在该方法上，可以认定CPU消耗过高是该方法被频繁调用，且消耗CPU资源过多引起。at java.util.ResourceBundle.getClassContext(Native Method)at java.util.ResourceBundle.getLoader(ResourceBundle.java:419)at java.util.ResourceBundle.getBundle(ResourceBundle.java:603)at com.kingdee.util.enums.Enum.getAlias(Enum.java:423)at com.kingdee.util.enums.Enum.toString(Enum.java:381)at java.lang.String.valueOf(String.java:1505)at java.lang.StringBuffer.append(StringBuffer.java:220)at com.kingdee.bos.metadata.bo.BusinessObjectIputeMethodType(BusinessObjectInfo.java:843)at com.kingdee.bos.metadata.bo.BusinessObjectInfo.getAllMethods(BusinessObjectInfo.java:819)at com.kingdee.eas.ep.plugin.PluginServiceAdaptor.getMethod(PluginServiceAdaptor.java:148)at com.kingdee.eas.ep.plugin.PluginServiceAdaptor.execute(PluginServiceAdaptor.java:86)at com.kingdee.bos.service.BOSServiceManager.doService(BOSServiceManager.java:65)at com.kingdee.bos.service.AbstractServiceManager.doService(AbstractServiceManager.java:92)3.2.3. Jprofiler. 工具使用具体使用网上很多文章介绍，在此不做详解，下面给篇网上金蝶中间件一位同事些的指导文章/blog/cns!80F376A8791573C8!313.entry. 分析思路该工具可以分析多类问题，其主要优势是分析CPU热点，通过CPU视图，截取一段时间段的调用堆栈信息，停止后我们逐层分析消耗CPU多的方法，逐层深入分析，有些问题可能集中在一个地方爆发，这种情况很容易定位，如大连中升的问题；有些问题过于分散而一下子难以看出问题，这时要继续往下挖掘有用的信息，直至找到问题点，如BOS6.3 4-5月份的集成测试CPU消耗高的问题。. 分析案例11. 问题BOS6.3 4-5月份集成性能测试CPU消耗比以往高处一倍，CPU出现明显瓶颈2. 分析通过Jprofile的CPU分析视图，层层分解，发现每个可疑点最后都能调用到动态配置平台，最后调用到BOS的枚举类com.kingdee.util.enums.Enum的toString方法，最后经过开发修改，高消耗CPU的问题得到解决,剖析截图如下. 分析案例11. 问题大连中升项目3个强并发压力测试,发现响应时间比较长，应用服务器CPU消耗过高，能达到60%。 2. 分析通过Jprofile的CPU视图，立马可发现主要消耗在一个具体的JSP页面上，此时已经很明确的告诉开发具体的修改地方3.2.4. jca401jca401是IBM公司提供的一个java线程分析工具，主要用来分析死锁、锁等待、线程的阻塞情况，该工具通过打开jvm的线程dump文件即可对当前线程状况进行分析。. 工具使用1 通过Java jar jca401.jar即可运行工具，启动后如下图2 通过file菜单打开dump文件,点击选中的文件，即可看到汇总信息,如下图3 通过Analysis菜单的Monitor detail分析细节信息,可以看到锁信息已经相应的java堆栈. 分析思路通过观察线程的阻塞的状态已经JAVA 线程调用堆栈，可以定位到具体类的具体方法已经某行代码上，再结合代码的分析可快速定位问题. 案例1. 问题云平台并行发布元数据出现等待超时错误2. 分析通过threaddump工具发现出现100多个线程等待，然后通过工具http:/serverip:port/easportal/dump.jsp?type=javadump生成线程dump文件,然后通过jca401工具打开文件诊断，工具提示死锁信息，通过锁信息跟调用堆栈发现，多线程调用经常在一个用来做元数据缓存的HashMap 上发现死锁,具体分析图如上面工具使用过程中的三幅图。3.2.5. ha404ha404是IBM提供的一个内存堆栈分析工具，用来分析大对象创建以及内存泄露等问题特别有用，目前金蝶分析oom主要就是通过此工具。. 工具使用1. 通过java -jar -Xmx1024m ha404.jar打开工具，如下图备注：在实际分析的过程中根据dump文件的大小来设置最大需要内存，有时候客户现场的dump文件很大，达到2G，这时候需要到64位的aix机器下打开，打开过程也需要很长时间，所以平时分析OOM问题的时候，我们实例的内存最好不要设置过大2. 通过file菜单打开dump文件，这个时候一般需要等待很长时间，打开后如下图3. 通过对内存引入堆栈的逐层展开找到主要内存问题点. 分析思路逐层分析，找到占用内存最多的点紧系分析，内存泄露一般来说主要由于持续累积的分配内存而不释放导致的，我们主要定位到泄露点就能找到解决问题的办法. 案例1. 问题供应链单据只要连续打开几十次客户端就崩溃掉2. 分析通过分析dump文件，发现供应链里每次打开一个UI都对其缓存起来，这样打开多了，客户端内存不够用就导致了OOM3.2.6. ga401ga401工具是一个用来分析JVM GC效率的工具，通过GC的次数、全GC的次数以及GC消耗的时间来判断当前应用程序的健康程度。3.2.7. jconsole. 工具使用1. 在服务器端打开JDK中提供的Jconsole工具,一般在 %JAVA_HOME%/bin下面,打开的窗口如下2. 输入访问地址连接服务器的JVM在高级页签中输入访问地址，如下，地址跟端口号视具体情况而定service:jmx:iiop:/jndi/corbaname:1.205:6912#jmx/rmi/RMIConnectorServer3. 分析