关于J2EE中软件基础结构的瓶颈

核心提示：可扩展性是系统中的一个非常重要的非功能性需求，但系统中可能有多个瓶颈会阻碍系统的扩展性，关于J2EE中软件基础结构的瓶颈，在这篇文章中，我们尝试分析软件基础结构成为瓶颈的案例，假如有足够的硬件资源就在同一台机器上跑群集否则在多台机器中配置，性能架构师：是的，而不考虑硬件资源上的限制（如CPU、磁盘空间、网络速度等），下

　　可扩展性是系统中的一个非常重要的非功能性需求。但系统中可能有多个瓶颈会阻碍系统的扩展性。在这篇文章中，我们尝试分析软件基础结构成为瓶颈的案例，而不考虑硬件资源上的限制（如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的机器来运行应用的实例。在增加机器后，吞吐量几乎翻了一倍。在这里我们确信数据库服务器不会成为瓶颈。
　　
　　注：在上面的两台机器的测试中，负载平衡是通过一种不增加应用服务器实例功能负载的方式来处理的。但是在实际的生产环境中很难做到。
　　
　　因为我们观察到8CPU的机器被没有被完全利用，所以我们使用4CPU的机器重新测试了一遍。测试的结果可以在下表中看到，分别对应配置1和2。4CPU的配置几乎被完全利用了，这意味着使用4CPU的配置比8CPU的配置更实际，因为前者花费更少。
　　　
　　小结
　　
　　这些实验指出了软件基础结构如应用服务器实例可能成为瓶颈，并给出了一些解决方案来减轻这种问题（包括在相同或不同机器上的群集）。这个问题需要在J2EE应用的负载计划或大小确定时优先考虑，因为这直接影响到应用的扩展性。这种想法很重要，下面我通过一个情景对话来表达。
　　
　　项目经理：你的意思是应用服务器（代表软件基础结构）会成为系统的瓶颈。
　　性能架构师：是的
　　
　　项目经理：那为什么这种情况不是经常发生。
　　性能架构师：是的，因为有时候瓶颈首先发生在硬件或应用本身。这时候应用服务器还没有使用到所有的扩展性。
　　
　　项目经理：这是事实。那么解决这种瓶颈的方法就是使用群集。假如有足够的硬件资源就在同一台机器上跑群集否则在多台机器中配置。
　　性能架构师：是的。这也是在这篇文章中所得到的。