金蝶BOS性能测试分析分享

金蝶B O S性能测试分析分享Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998金蝶BOS性能测试分析流程目录1.1. 简介最近通过版本的4-5月份集成测试与云平台的性能测试两个案例分析，发现性能测试只定位发现问题的工作方式不利于问题的快速处理，进而错过问题的最佳处理时机，给后续的发版带来很高的风险，4-5月份的集成测试只反馈CPU高消耗的现象与WEB的jprofile分析文档，因开发人员过忙与缺少实际环境而把问题一直耽搁着，这个问题本来在6月1号就发现了，结果到了7月5号迫不得已才组织人员协同分析定位问题，问题定位后也快速解决了问题；而云平台的性能测试我一直跟踪并协助定位性能问题，问题定位后，开发迅速修改代码，整个过程发现的几个重大性能问题都得到了快速的解决，通过对比这两个性能测试案例，得出只有快速定位问题才能高效的解决问题，只反馈问题现象，缺乏足够的依据，开发人员很难快速修复问题。

为了在BOS性能测试过程中快速定位问题以及在调优测试中快速找到性能提升点，特意整理在分析性能问题过程中涉及到的一些工具与方法，以便快速解决问题，本文将从用例分析、问题现象、问题分析、问题定位、辅助工具等方面规范性能问题的分析过程以及工作过程中的输出文档。

1.2. 参考资料2.1. 概述处理任何问题都有一套方法，性能测试分析过程也一样，我们平常测试发现的问题只是问题的表现，我们要透过现象逐步分析到问题的本质，透过本质我们才能快速解决问题，下面我就按经验来整理一下性能问题的分析思路与通用流程。

2.2. 分析思路我们通过一个倒金字塔模型来整理一个分析思路，由上至下逐步聚焦问题,测试过程中首先是会发现问题，发现性能问题后，我们第一步要确认是否是测试用例设计不当而导致的，如果不是我们就要用后续提到的各种工具与方法出具问题分析结果，根据分析数据推断出可能存在的代码可疑点，然后与开发一起如果修改问题。

2.3. 步骤结果输出2.4. 分析流程下图整理一个在性能测试过程中发现性能问题而进行问题定位的分析流程，本流程里不涉及到硬件绝对瓶颈的问题，如磁盘空间不足，另外应用服务器跟数据库服务器的参数都按照产品配置说明进行了正确配置，本流程图只用来指导分析软件本身存在的问题。

3.1. 概述本章节对分析各类问题涉及到的工具进行介绍，在问题分析中，不同的问题都有对应的工具进行辅助分析，选择正确的工具有助于快速定位问题，从而提高问题的处理效率。

3.2. 工具分类介绍一些将从IE、Java、数据库三方面对使用到的工具以及基本使用进行讲解，以此给在性能分析中提供参考3.2.1.HttpWatch3.2.1.1. 工具使用只要打开HttpWatch，然后点击录制，访问IE后，所有的HTTP交互就被录制下来，3.2.1.2. 分析思路通过是否使用catch来判断实际跟服务器起的交互次数，通过响应时间来判断哪个http请求消耗的时间较长，以此来初步判断存在问题的页面3.2.1.3. 分析案例1.问题大连中升项目3个强并发压力测试,发现响应时间比较长，应用服务器CPU消耗过高，能达到60%2.分析通过httpWatch分析http交互过程，重点分析页面,发现该页面每次都要向服务器提交提交60K左右的内容,从提交的内容看出，提交把一大片的HTML代码都提交到WEB SERVER了,而从下面的分析图中看到，一个实际的业务，其实业务本身性能很好，花了秒，而实际花了秒，从这看出性能很差劲,需要优化3.2.2.ThreadDump3.2.2.1. 工具使用1.通过调用EAS门户访问dump工具,访问端口号视具体情况而定，如下2.在打开的界面中分析线程的数量以及线程的调用堆栈3.2.2.2. 分析思路通过分析总线程的数量或某类线程的数量，如果出现的太多，而次数系统运行状况不好，则可以怀疑某类线程调用出现问题，通过线程的调用堆栈，可以推出哪些类的方法存在问题3.2.2.3. 分析案例1.问题金汉斯反馈最近打了几个补丁（有若干关联补丁）后，应用服务器CPU持续100%，系统功能整体非常慢，登录超过1分钟，单据提交10几分钟才能完成2.分析连线看了一下，应用服务器内存消耗正常，排除GC引起的CPU消耗异常。

查看threaddump，发现总是会有几十个活动的线程，虽然线程对应的业务方法各异，但都调用到动态扩展平台的方法，且堆栈大多停留在该方法上，可以认定CPU消耗过高是该方法被频繁调用，且消耗CPU资源过多引起。

a:419)3.2.3.Jprofiler3.2.3.1. 工具使用具体使用网上很多文章介绍，在此不做详解，下面给篇网上金蝶中间件一位同事些的指导文章3.2.3.2. 分析思路该工具可以分析多类问题，其主要优势是分析CPU热点，通过CPU视图，截取一段时间段的调用堆栈信息，停止后我们逐层分析消耗CPU多的方法，逐层深入分析，有些问题可能集中在一个地方爆发，这种情况很容易定位，如大连中升的问题；有些问题过于分散而一下子难以看出问题，这时要继续往下挖掘有用的信息，直至找到问题点，如 4-5月份的集成测试CPU消耗高的问题。

3.2.3.3. 分析案例11.问题4-5月份集成性能测试CPU消耗比以往高处一倍，CPU出现明显瓶颈2.分析通过Jprofile的CPU分析视图，层层分解，发现每个可疑点最后都能调用到动态配置平台，最后调用到BOS的枚举类的toString方法，最后经过开发修改，高消耗CPU的问题得到解决,剖析截图如下3.2.3.4. 分析案例11.问题大连中升项目3个强并发压力测试,发现响应时间比较长，应用服务器CPU消耗过高，能达到60%。

2.分析通过Jprofile的CPU视图，立马可发现主要消耗在一个具体的JSP页面上，此时已经很明确的告诉开发具体的修改地方3.2.4.jca401jca401是IBM公司提供的一个java线程分析工具，主要用来分析死锁、锁等待、线程的阻塞情况，该工具通过打开jvm的线程dump文件即可对当前线程状况进行分析。

3.2.4.1. 工具使用1．通过Java –jar 即可运行工具，启动后如下图2．通过file菜单打开dump文件,点击选中的文件，即可看到汇总信息,如下图3．通过Analysis菜单的Monitor detail分析细节信息,可以看到锁信息已经相应的java堆栈3.2.4.2. 分析思路通过观察线程的阻塞的状态已经JAVA 线程调用堆栈，可以定位到具体类的具体方法已经某行代码上，再结合代码的分析可快速定位问题3.2.4.3. 案例1.问题云平台并行发布元数据出现等待超时错误2.分析通过threaddump工具发现出现100多个线程等待，然后通过工具生成线程dump文件,然后通过jca401工具打开文件诊断，工具提示死锁信息，通过锁信息跟调用堆栈发现，多线程调用经常在一个用来做元数据缓存的HashMap 上发现死锁,具体分析图如上面工具使用过程中的三幅图。

3.2.5.ha404ha404是IBM提供的一个内存堆栈分析工具，用来分析大对象创建以及内存泄露等问题特别有用，目前金蝶分析oom主要就是通过此工具。

3.2.5.1. 工具使用1.通过java -jar -Xmx1024m 打开工具，如下图备注：在实际分析的过程中根据dump文件的大小来设置最大需要内存，有时候客户现场的dump文件很大，达到2G，这时候需要到64位的aix机器下打开，打开过程也需要很长时间，所以平时分析OOM问题的时候，我们实例的内存最好不要设置过大2.通过file菜单打开dump文件，这个时候一般需要等待很长时间，打开后如下图3.通过对内存引入堆栈的逐层展开找到主要内存问题点3.2.5.2. 分析思路逐层分析，找到占用内存最多的点紧系分析，内存泄露一般来说主要由于持续累积的分配内存而不释放导致的，我们主要定位到泄露点就能找到解决问题的办法3.2.5.3. 案例1.问题供应链单据只要连续打开几十次客户端就崩溃掉2.分析通过分析dump文件，发现供应链里每次打开一个UI都对其缓存起来，这样打开多了，客户端内存不够用就导致了OOM3.2.6.ga401ga401工具是一个用来分析JVM GC效率的工具，通过GC的次数、全GC的次数以及GC消耗的时间来判断当前应用程序的健康程度。

3.2.7.jconsole3.2.7.1. 工具使用1.在服务器端打开JDK中提供的Jconsole工具,一般在 %JAVA_HOME%/bin下面,打开的窗口如下2.输入访问地址连接服务器的JVM在高级页签中输入访问地址，如下，地址跟端口号视具体情况而定:6912#jmx/rmi/RMIConnectorServer3.分析内存视图4.分析线程视图3.2.7.2. 分析思路用Jconsole工具主要分析内存跟线程，看内存是否够用以及是否能正常回收，以此来判断内存是否设置太小或者存在内存的泄露，线程视图可以用来判断当前的线程是否创建过多或者存在很多等待状态的线程，如果存在大量阻塞状态的线程，则需要分析是否存在死锁或者严重的锁等待性能问题。

3.2.8.TOP SQL3.2.8.1. 工具使用1.在oracle用户下检测em服务是否启动，如果启动就按给定的地址用IE访问,如下图,提示已经启动，那我们可用访问,一般用IP地址访问，将访问地址改为2.用IE登录EM3.切换到performance页签然后到Top Activity,然后查看TOP sql4.查看执行计划3.2.8.2. 分析思路通过oracle OEM的顶层会话观察活跃SQL的情况，对活跃的SQL查看其执行计划,重点分析全表扫描的表，如果表记录超过1万行且进行了全表扫描，则要重点分析3.2.8.3. 分析案例1.问题深圳建滔系统08年9月上线的时候系统非常慢，应用服务器资源消耗不高，数据库IO等待很严重。

2.分析通过分析TOP SQL分析关键SQ语句，发现有一条SQL语句对一个大表进行全表扫描,后面开发通过修改代码优化SQL语句来解决此问题，如下图。