JBoss 3.23+MySQL 4.0 +eStore
Borland的Optimizeit 5.0

JMeter
参数配置：10个用户 并发运行50次或无限时间（测试内存泄漏）。

树显示页面，treeAction.do

通过Struts的Action，通过JdonSD的AOP拦截器调用CategoryXXXX相关EJB。这个测试过程并没有激活缓存功能，每个树型节点都是通过后台EJB从数据库直接读取。

客户端除了10个用户第一次响应时间是20秒，以后平均响应时间在6秒左右，并且保持这个响应时间结束。

上述结果是因为服务器端有 Optimizeit 5.0参与影响响应时间，正常反应是在1秒以内。

选取第二个线程跟踪分析，按这里观看统计结果，从图中可见，JdonSD构件库并没有成为占用CPU的主要者，主要者而是业务逻辑com.jdon.estore为首的与eStore相关的功能类，从而证明JdonSD构件库基本不影响具体项目的CPU占用。

按这里观察统计结果，从图中看出，除了JdonSD构件库启动容器占用少量内存，这个内存只占用系统内存的0.02%，数量也有限 16个。其他占据内存更少，这说明JdonSD构件库在内存方面并不会影响主要影响项目。

1. 某个目录下商品列表第一页，productList.do?catId=20
2. 数据库中只有10个数据
3. 服务器端未启动Optimizeit

JdonSD构件库的缓存拦截器将优化提高性能

Jmeter测试结果平均响应时间700毫秒,如图：

Jmeter测试结果文档

1. 某个目录下商品列表最后某页，productList.do?start=8000&count=20
2. 数据库中有9000条记录
3. 服务器端未启动Optimizeit

JdonSD的批量数据查询框架将发挥作用，提高大数据量查询性能。

Jmeter测试结果平均响应时间1000毫秒,

Jmeter测试结果文档

1. 某个目录下商品列表最后某页，productList.do?start=8000&count=20
2. 数据库中有9000条记录
3. 服务器端启动Optimizeit

1. JdonSD的批量数据查询框架将发挥作用，提高大数据量查询性能。
2. 运行时间为8个小时。

内存中com.jdon相关实例个数非常少，见这里报告。

最多的String类中涉及的具体类中，都是有关JdonSD缓存类有关，但是个数没有呈无限增长趋势，见这里报告