使用JMETER 测试ORACLE ADF的BC层性能

原文地址：http://adfeye.sinaapp.com/?p=192

前言

    研究ADF技术已经有8年多时间了，从开发效率上来说，ADF技术有很大的优势。但对于其性能表现的认识一直很模糊。之前也测试过，可是后来发现由于登录/认证方面的问题，导致测试结果不够准确。

    今天要测的是ADF-BC层得性能，而不是Faces的性能。我要验证的是ADF能否在较高并发下承担起Server端的巨大压力，因为ADF的前端可以用其他技术进行替换。

Oracle support说没有官方对ADF的性能测试报告，因此才有此文。。。

    受环境限制，本次测试全部采用家用PC和个人的笔记本进行，由于网络也不咋地，普通路由器，因此尽可能排除网络因素的影响。。。

目的

验证ADF框架的性能表现。不考虑网络，业务逻辑等非框架因素的影响。

测试功能

项目包含一个单纯的Resource，实现对LOAD_TEST表的CRUD操作

表结构

测试内容

使用JMeter进行基于Http request的压测，实现对单张表，单Java对象的基本CRUD操作。全部请求均通过同一个Resource执行CRUD操作。

Resource：

to upload

Jmeter配置

首先创建一条记录，间隔1秒钟，执行查询操作，间隔1秒钟，执行修改，间隔1秒钟，执行删除。

每次请求结束会根据返回内容判断是否执行成功。

Jmeter的配置，附件 toupload

对ADF来说，相当于模拟设置数量的匿名用户同时执行4次操作，执行n遍。（n为循环次数，可设置）

测试FirstDay  2015年9月3日

环境：

笔记本电脑一台，Window7 64bit，双核i7,8G内存

说明

本次测试的所有软件都在同一台windows笔记本内完成，包括Jmeter，Weblogic，Oracle数据库。

由于使用地址均为localhost，可以忽略网络状况。

内存分配

总8G，Oracle数据库就占了接近4G，weblogic先用默认的256~512M吧 

weblogic内存配置

@REM 64 bit JVM memory settings

 set SERVER_MEM_ARGS_64=-Xms256m -Xmx512m

 set SERVER_MEM_ARGS_64HotSpot=-Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m

 set SERVER_MEM_ARGS_64JRockit=-Xms256m -Xmx512m

开始测试 FirstDay 第一次

200用户，执行5次，响应时间有点长。。。

单位（ms）

开始测试 FirstDay 第二次

模拟，500用户压测时，CPU占用较高。（按下截图快捷键时，PUT和Delete的Max请求时间增加了2秒~）

开始测试 FirstDay 第三次

800用户压测

开始测试 FirstDay 第四次

1000用户

调整内存

 @REM 64 bit JVM memory settings

 set SERVER_MEM_ARGS_64=-Xms512m -Xmx1024m

 set SERVER_MEM_ARGS_64HotSpot=-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=1024m

 set SERVER_MEM_ARGS_64JRockit=-Xms512m -Xmx1024m

从效果看，调完内存后响应时间反而变大了

  set SERVER_MEM_ARGS_64=-Xms1024m -Xmx2048m

  set SERVER_MEM_ARGS_64HotSpot=-Xms1024m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=2048m

  set SERVER_MEM_ARGS_64JRockit=-Xms1024m -Xmx2048m

加大内存后没有任何改善，从图上看是磁盘瓶颈了

结论

可以看到在500用户并发量时，本机测试效果显示操作时间在9秒以下，没有报错。

即使将并发用户数量调到到1000，后台也没有出现报错问题。但由于所有测试软件都在同一台笔记本电脑内运行（Jmeter，weblogic，oracle），因此，受硬盘IO限制，测试时发现无论如何设置运行weblogic的内存都无法提升性能（反而略微下降）。

考虑到所有程序都是在一台笔记本上运行，后台始终没有报错我已经很欣慰了。。。

接下来，我会尝试将数据库分到另一台PC上去，然后用Oracle之外的数据库，和开源一些的容器。并且尝试将数据库和压测软件分离到其他机器上运行。

测试SecondDay 2015年9月6日

我将数据库挪到另一台家用PC机上，通过网线与家用路由器连接。

原笔记本依然运行Jmeter，Weblogic，新建weblogic domain。

笔记本通过无线网络与路由器连接。

条件艰苦。。。还懒，不爱找网线。。。

测试SecondDay 第一次压测

使用默认的内存大小，256-512M测试。

1000用户，执行2次操作

可以看到，全部请求都在4秒钟之内完成。就我这种配置，和weblogic的默认内存大小来说，还是蛮给力的

测试SecondDay 第二次压测

接下来，将weblogic内存提高进行测试。

果然更快了，1000个用户普遍在3秒左右完成。

数据库负载情况（为什么有两条线呢？因为第一次测试时受首次加载影响，响应时间达到9秒，又测了一次~）

weblogic数据源的负债情况（最多时才用了45个数据库连接，1000个用户啊）

测试SecondDay 第三次压测

2000用户执行一次操作时，GET方法有少量org.apache.http.NoHttpResponseException: The target server failed to respond错误

响应时间较长

测试SecondDay 第四次压测

继续扩大weblogic内存

1000用户，持续执行

数据库

可以看到1000用户持续较长时间（20分钟左右）执行时，系统依然能够保持响应时间在4秒钟以下。

总结

在本轮测试中，2000并发执行一个循环时系统不会报错。2000并发执行2个循环时，系统的GET方法会有少量报错。

1000并发可以稳定在4秒钟内执行完毕。

在实际场景下，考虑到单个用户的ThinkTime不可能只有1秒，并且大部分操作只会返回静态网页和资源文件，并不会执行太多的CRUD操作，以这种家用配置支持10000个用户应该是可以的（当然，要忽略网络…）。