实验和观察
我们会在一个8CPU平台上为J2EE应用做一项实验，下面是实验的代码:
String mem = request.getParameter("memory");
if (mem != null && !mem.equals("")) {
int mem_kbytes = Integer.parseInt(mem);
byte[] i = new byte[mem_kbytes*1024];
}
在每一次测试中，这些J2EE线程会请求创建一个特定内存大小的对象。在一个多用户负载测试中，我们观察到下列的数据:响应时间、吞吐量和资源利用率。
我们将JVM堆大小设置为一个较大的值这样就可以减少垃圾回收的次数。我们注意到即使负载增加，“垃圾回收暂停时间”与“运行总时间”的比率始终在1:35左右，因此我们认为他在这项实验中的影响较小。结果如下图2。
Figure 2. Results of shared memory access on multi-processor platform
这个实验的环境如下:
1、应用服务器：WebLogic7
2、JVM：Sun JVM 1.3
3、操作系统：Windows 2000高级服务器版
4、硬件：Intel Dell PowerEdge 8450 (8Intel Xeon 800MHz 处理器, 4GB RAM)
5、网络：100Mbps Cisco网络
6、负载测试工具：WebLoad
我们观察到在增加特定内存大小的对象的负载时，吞吐量增加的比率与CPU利率的增加比较并不相同。当然，响应时间的增加也不是线性的。这些实验清晰地显示了这些J2EE线程的高内存需求导致系统内的争用并且成为J2EE可扩展性的瓶颈。我们还观察到这些线程访问内存和创建对象所花费的时间随着处理利用率的增加而增加。这可以从负载的增加导致服务请求的增加中看出来，如图3中特定内存大小的Java对象的创建图表。
Figure 3. Increase in service demand versus load for Java objects of different memory sizes
