JEE中软件基础结构的瓶颈.docVIP

J2EE中软件基础结构的瓶颈 2005-11-21 可扩展性是系统中的一个非常重要的非功能性需求。但系统中可能有多个瓶颈会阻碍系统的扩展性。在这篇文章中，我们尝试分析软件基础结构成为瓶颈的案例，而不考虑硬件资源上的限制(如CPU、磁盘空间、网络速度等)。下面我们将探讨一下这个问题。 　　下面是一些整篇文章中用到的一些术语: 　　·吞吐量:系统支持的每秒能够处理的事务个数。　　·服务请求:每个事务中特定硬件的使用率，等于硬件使用率除以吞吐量。　　·硬件资源:指处理器、内存、磁盘和网络。　　·软件资源:指WEB线程、执行线程、BEAN池及数据库连接池等。　　·预计时间:用户预计两次并发提交请求之间的时间。　　·短时间法则:一个验证测试及确信测试环境不是瓶颈的法则。　　·响应时间:用户等待他提交的请求返回响应的时间。 　　理论基础 　　任何J2EE应用通常都有下面几个层次，如图1: 　　1、硬件基础结构资源(处理器、内存、磁盘和网络) 　　2、软件基础结构资源(JVM,WEB服务器、应用服务器、数据库服务器) 　　3、软件应用(J2EE应用) 　　Figure 1. Snapshot of a J2EE system 　　这儿有两个可能性导致瓶颈:硬件成为主要瓶颈或者软件成为主要瓶颈。在第一种情况，硬件资源不足够而软件资源很充分，如图2。随着负载的增加，硬件资源成为瓶颈，而软件可以继续扩展。减轻这个瓶颈的方案通常是扩大或者增加硬件。 　　Figure 2. The hardware pipe becomes a bottleneck 在第二种情况，硬件资源是足够的而软件资源相对有限。随着负载的增加，软件资源成为瓶颈，如图3。减轻这种瓶颈的方案通常是使用软件群集或优化软件。 　　Figure 3. Software pipe becomes a bottleneck 　　应用服务器如何工作? 　　来考虑一下应用服务器的内部机制。应用服务器的基本功能包括事务管理、数据持久、对象池、SOCKET处理和请求处理。这些功能的流程如图4。有各种组件来处理这些功能。这些组件需要同步应用服务器中的线程来维护数据的一致性并操作数据。虽然这种同步对应用服务器的功能正确性是必须而且有用的，但是也成为高负载的限制，即使有足够的硬件资源。 　　Figure 4. Internals of an application server 实验 　　为了理解瓶颈的状况，我们在基于Windows/Intel平台用流行的J2EE应用服务器来测试一下JAVA PETSTORE应用。一些测试用例如PetStore应用的浏览和购买周期来测试扩展性。我们确信整个测试环境(包括操作系统、JVM、应用服务器和应用自身)已经尽可能优化了，而且J2EE应用没有任何瓶颈或同步问题。我们使用了多用户负载测试并观察了响应时间、吞吐量、资源利用率等指标。 　　环境如下: 　　1、 J2EE PetStore应用　　2、 J2EE应用服务器　　3、 Sun JVM 1.3　　4、 Windows 2000高级服务器　　5、 Intel Dell PowerEdge 8450 (8Intel至强800MHz处理器, 4GB RAM)　　6、 100Mbps Cisco dedicated network　　7、 负载测试工具WebLoad 　　在这个测试中我们看到即使有足够的硬件资源，应用服务器的实例个数限制了扩展的能力。在这里软件资源(如执行线程、BEAN池大小、数据库池和其他应用服务器参数)优化后即使这些资源不足也不会影响系统的扩展。下面我们来研究一下减轻这种问题的方案。 　　注:Sun J2EE PetStore可以被更多地优化来改善性能和可扩展性。 　　解决方案 　　同一机器上的群集 　　当吞吐量满载了应用服务器的一个实例时，需要增加一个实例来减轻这种问题。这个方案如图5。 　　Figure 5. Instance clusters on the same hardware box 当前机器的CPU使用率只有40%因而有足够空间来增加一个实例。我们可以发现在增加了实例后，吞吐量也增加了50%，如表2 　　在不同机器的群集 　　当吞吐量满载了应用服务器的一个实例时，机器的CPU使用率只有40%。因为8CPU的机器未完全利用，所以我们测试一下更低配置的机器。现在我们使用两个4CPU的机器，如图6。 　　Figure 6. Instance clusters on different hardware boxes 　　我们发现4CPU机器的CPU使用率已达到80%，再增加实例也没有什么用处了。因此我们又增加一台4CPU的机器来运行应用的实例