|
HTTP会话对象 VS 有状态EJB |
作者：未知 发布时间：2005-03-12 来源：JSP天空网
|
作者：Peter Zadrozny
时间：2002-10-16 15:56:34
会话处理的一大论争是在HTTP会话对象中存储状态和使用有状态会话bean存储状态间性能上的不同。 我和我的同事曾认为在HTTP会话对象中储存数据更有效，如同我们印象中的在EJB容器中会话bean的上储存数据会带来更多的系统开销。因此，我们对测量每个方法的性能很感兴趣，来证明或反驳我们的最初观念。
为了进行测试，我们创建了一个小应用程序用来在HTTP会话对象中或是在有状态会话bean中存储确定数量的随机产生的内容(size=number_of_bytes_to_store)。我们的应用程序由一个单一的类：SessionServlet组成，我们将它用作servlet和会话监听。Servlet方法负责处理相关联的会话中的请求和存储数据，它使用指定的存储方法。当servlet要求使用参数type=0时，它存储数据在一个HttpSession对象中，当参数为type=1时，存储数据在有状态会话bean中。当我们使用会话bean时，为了和客户端的bean实例相关联，我们仍然需要HTTP会话对象来存储bean的句柄。
不仅是servlet，SessionServlet也继承HttpSessionListener接口。当相关联的会话无效时我们要确保所有的会话bean都被移除。如果我们没有明确的移除会话bean?D?D通过调用ejbRemove()方法，就像你待会儿将会看到的?D?D它们将由bean容器来钝化，其结果将会对性能有戏剧性的影响。
测试环境是基于WebLogic 服务器 6.1版 SP2 (15个执行线程)。我们使用JDK 1.3.1-b24 HotSpot服务器并且我们唯一定义的参数是堆栈空间128MB(-ms 和 -mx 相同)。硬件环境是Sun Ultra 60服务器，双Ultra SPARC II 450 MHz，512MB的内存， 运行 Solaris 2.7。 所有的测试都在100Mbps的专用网络上进行，在该网络上唯一的信息流均是由测试本身产生。
一旦SessionServlet被部署，我们使用Grinder (http://grinder.sourceforge.net ) 来产生测试负载，在每一个负载中模仿用户执行测试脚本(参看 Listing 1)。
正如你所看到的，每个请求存储不同数量的字节。 存储的字节总数是每个会话3,200个。同样要注意到在请求之间没有间歇的时间。 我们这样做的目的是为了最大限度的对系统上施加压力。
为了证实有状态beans在每个HTTP会话的最后被移除，我们在WebLogic服务器中设定HTTP会话的超时时间为5秒，并且限定在开始一个新的HTTP会话前测试脚本要休眠6秒。
我们用100，200，300，400，和500个并发的当前用户进行测试，在测试进行期间每个人都以一种顺序的方式执行测试脚本。 示例的大小在忽略了测试执行的头3分钟后是10分钟。平均响应时间的结果可以在图1中见到。
<图1 平均响应时间
图中给出了平均响应时间的集合，它是所有在测试脚本中标记的10个请求的平均响应时间的平均值。我们也为第一个请求出示平均的响应时间，我们猜测它可能会比其他请求需要多点的时间，因为它必须建立HTTP连接并且创建HTTP会话对象 (同理当type=1时有状态会话bean也会是这样)。
注意到当负载增加时第一个请求的响应时间变得比响应时间的总体值小。这表明在高负载下HTTP会话对象的处理比建立HTTP握手连接以及创建HTTP会话对象花费的时间要多。
看图2，总的处理率，我们注意到当曲线还没有稳定时它是没有达到应用服务器的最大处理能力的。
图2 总的处理率
网络资源利用变化率从100个用户平均利用率不足1 %上升到500个用户利用率大约4 % ( 参看图3)。
图3 网络资源利用变化率
类似的情况用在计算机运行应用程序时的CPU利用率的观测上，它的变化从100个用户平均利用20 %升级到500个用户利用大约90 %的CPU资源 (参看图4)。
图4 计算机运行应用程序时的CPU利用率
下一个试验的设置用有状态会话bean通过指定type=1作为servlet的一个参数。令我们吃惊的是，结果基本上是相同的就像在图5中看到的比较。
图5 有状态会话bean指定type=1
就处理率来说，最大的差异约是1 %，这可以被忽略掉。我们注意到了这个测试中设备的网络和CPU利用与用HTTP会话对象测试基本上是相同的。
我们必须承认有状态会话bean没有使用EJB容器提供的安全特性。然而，有趣的是，我们发现在测试条件下把数据保存在HTTP会话对象中的开销和保存相同的数据在有状态会话bean中的开销大约是相同的。退一步说，它也同样带来了惊奇。我鼓励你去测试你的情况，特别要注意在测试脚本中你所用的间歇时间。虽然我相信你会看到不同的性能数据，我还是期望两个模型间的比较开销可以大约相同。
间歇时间可以对你得到的结果有非常大的影响。我们在观测高压环境中的性能时故意没有用间歇时间。在正常情况下你是必须在你的应用程序中用到间歇时间的。
使用ejbRemove
在J2EE中一个最常见的程序错误是，一旦使用了EJB，会忘记明确的终结或移除它们。它经常发生在从servlets 调用EJB 时。我们前面提到了我们在前面的测试中非常注意确保EJBs被移除了。我们通过一个会话监听来完成它，监听确保了在一个会话终结前，可能用到的所有的bean 都被终结。此外，我们要确保测试脚本一直等到HTTP会话超时，才给监听时间来移除EJBs。
没有移除应该被移除的EJB意味着在性能上会付出有很高的代价。基本上，发生的是EJB将被钝化，从容器中移除EJB的一种相当笨的方法。你应当知道，钝化是开销非常大的操作，因为它首先要串行化bean，然后再往磁盘上写。
为了清楚的阐明钝化的开销，我们修改了先前的测试中用到的servlet。我们通过添加一个type=2的测试来实现它，这个测试是当HTTP会话终结时没有移除有状态会话bean。性能上的差异非常大我们不得不在图6的表中使对数来表示。处理率的情况更糟糕（参看图7）。
图6 钝化的花费
图7 处理率中的钝化
如果我们移除了EJB ，当用户增加时，吞吐量也增加；如果我们没有移除EJBs，吞吐量实际上是随着用户的增加而减小的。
结论
让人吃惊的发现了假定用了一种恰当的方法在会话终结时移除bean，那么在HTTP 会话对象中存储数据的开销基本上和用有状态会话bean 一样。没有这么做会在应用程序执行时产生消极的影响。但是知道这些bean 必须被移除是一回事，实际上能适时的做到又是另一回事了。事实上，它是一个相当可观的程序用来确保操作正确。在我们的情况，我们用会话监听装置监听会话的生命周期并且在bean钝化前的时刻删除它。对于你自己的应用程序，你可以用这种方法或其他任何你知道的可行的方法。在任何情况下，做任何最终决定之前总要确定适当的测试以及彻底分析系统。
感谢
这篇文章摘录自Peter Zadrozny写的J2EE Performance Testing （《J2EE 性能测试》 Expert Press, 2002年六月）。特别要感谢Bjarki holm 和Garenth Chapman ，他们帮助准备了测试用的应用程序。 |
| |
|
|
|
