金蝶BOS性能测试分析分享

相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

金蝶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.HttpWatch

3.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.ThreadDump

3.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.Jprofiler

3.2.3.1. 工具使用

具体使用网上很多文章介绍,在此不做详解,下面给篇网上金蝶中间件

一位同事些的指导文章

3.2.3.2. 分析思路

该工具可以分析多类问题,其主要优势是分析CPU热点,通过CPU视

图,截取一段时间段的调用堆栈信息,停止后我们逐层分析消耗CPU

多的方法,逐层深入分析,有些问题可能集中在一个地方爆发,这种情

况很容易定位,如大连中升的问题;有些问题过于分散而一下子难以看

出问题,这时要继续往下挖掘有用的信息,直至找到问题点,如 4-5月

份的集成测试CPU消耗高的问题。

3.2.3.3. 分析案例1

1.问题

4-5月份集成性能测试CPU消耗比以往高处一倍,CPU出现明显瓶

2.分析

通过Jprofile的CPU分析视图,层层分解,发现每个可疑点最后都

能调用到动态配置平台,最后调用到BOS的枚举类的toString方法,

最后经过开发修改,高消耗CPU的问题得到解决,剖析截图如下

3.2.3.

4. 分析案例1

1.问题

大连中升项目3个强并发压力测试,发现响应时间比较长,应用服务器CPU消耗过高,能

达到60%。

2.分析

通过Jprofile的CPU视图,立马可发现主要消耗在一个具体的JSP

页面上,此时已经很明确的告诉开发具体的修改地方

3.2.

4.jca401

jca401是IBM公司提供的一个java线程分析工具,主要用来分析死锁、锁等待、线程的阻塞情况,该工具通过打开jvm的线程dump文件即可

对当前线程状况进行分析。

3.2.

4.1. 工具使用

1.通过Java –jar 即可运行工具,启动后如下图

相关文档
最新文档