时间：2006-06-20 作者：Tom Barnes 浏览次数： 本文关键字：WebLogic Real Time, real time, Deterministic Garbage Collection, BEA JRockit, WebLogic Server, Tom Barnes, 实时, 确定性垃圾收集

文章工具  推荐给朋友  打印文章

摘要

　　BEA WebLogic Real Time 1.0 (WLRT)是一个基于标准的服务器，它支持需要快速可预测的响应时间和低延迟的应用程序。它对实时应用程序的支持是通过WLRT的JRockit JVM来实现的，该JVM使用了确定性垃圾收集机制(Deterministic Garbage Collection，DetGC)，这是一种支持极短暂停时间并在一个指定的窗口内限制这些暂停的总数目的动态垃圾收集算法。

　　通过将JRockit DetGC与Sun JVM的增量型垃圾收集(Incremental Garbage CollectionInc，GC)机制以及无DetGC的默认JRockit相比较，本文将分析DetGC特性的效力。为了阐明DetGC所提供的高效内存管理，本文包含了示例的Trader应用程序的延迟和吞吐量的图形化度量，以及提高性能所需的软件调优摘要。

BEA WebLogic Real Time简介

　　有一类新的企业应用程序，其延迟是至关重要的，如果不能在几毫秒之内执行，数据就变得失效无用了。BEA WebLogic Real Time (WLRT)瞄准的是具有低延迟、可预测的性能驱动需求的应用程序。WLRT是一个用于实时计算的有回复力的轻量级中间件解决方案。WLRT应用程序具有使用独立的Java或Spring框架，或者依赖于WebLogic Server的灵活性。前两个选项允许WLRT应用程序是轻量级的，后一个选项结合了一个具有企业级可靠性、可用性、可管理性和可伸缩性的低延迟解决方案。与非实时中间件不同，WLRT提供了严格的毫秒级延迟性能和可靠的服务级协议。

　　WLRT 1.0包括以下组件：

• BEA JRockit 5.0 R26——一个使用确定性垃圾收集(DetGC)的高性能Java虚拟机(JVM)。虽然所有的Java虚拟机都具有垃圾收集功能，但确定性垃圾收集避免了其他虚拟机中无法预测的暂停时间，从而支持最短的事务延迟。
• BEA WebLogic Server 9.1——一个可伸缩的企业就绪的Java Enterprise Edition (J2EE)应用服务器。WebLogic Server基础架构支持多种类型的分布式应用程序的部署，是一个基于面向服务架构构建应用程序的理想基础。
• Spring容器——一个分层的Java/J2EE应用框架，它提供了最全面的轻量级容器。通过允许开发人员使用Plain Old Java Object (POJO)以及实施模块化、可重用的编码实践，Spring有助于提高开发人员的生产率。

　　WLRT允许具有实时需求的客户利用标准的基于Java的基础架构所带来的好处，包括较高的开发人员生产率、较少的故障、一个已经验证的内核以及对标准的服从性。这就直接解决了金融服务公司以及许多其他行业在编写和维护实时应用程序方面所面临的挑战。

基准测试结果摘要

　　为了演示WLRT的效力，我们将对一个示例股票交易应用程序Trader进行调优，然后进行基准测试。运行的Trader应用程序由一个或多个反复执行报价(quote)和订单(order)请求的客户端组成。报价请求从一个WebLogic Server报价服务检索股票报价（通过JMS非持久性消息传递给一个MDB），而订单请求调用一个订单服务，该服务事务性地在一个仿真数据库中记录请求（通过JMS可靠的持久性消息传递给一个消息驱动bean (MDB)）。

　　JRockit JVM和Sun JVM都没有进行太多调优，因为我们的目标是产生无需对JVM进行太多手动调优就可以实现的结果。实际上，调优过程大部分都遵循标准的最佳实践，只有一点例外：服务器JVM内存被限定为256MB，以便为JRockit DetGC算法提供帮助。优化Trader应用程序所需的调优细节可参见Tuning Trader示例。

执行概要

　　这次基准测试的结果显示，采用DetGC的WLRT 1.0 JRockit JVM在吞吐量和延迟方面都要比采用IncGC的Sun JVM以及无DetGC的默认JRockit JVM执行得好。通常，性能关键型的实时应用程序需要牺牲吞吐量性能以换取更短的响应时间。然而，WLRT 1.0却能够在维持较高的吞吐量的同时极大地降低延迟。

　　实际上，采用DetGC的JRockit在测试中的延迟只有其他参与测试的JVM的延迟的五分之一，而且其吞吐量还能够高出17%。此外，没有采用DetGC时，JRockit所报告的GC暂停时间高达275毫秒；但是使用了DetGC之后，JRockit所报告的最大GC暂停时间大约为30毫秒，降低了很多。关于基准测试结果的更多信息，请参见扩展的两小时、两台机器基准测试和详细的基准测试图表。

初始的少量伸缩基准测试

　　在初始的基准测试中，运行了一系列短期的、单线程、单机器的测试，来比较对客户端和服务器运行确定性和非确定性垃圾收集的组合（分别在Sun和JRockit JVM上运行）。将Sun的增量型垃圾收集(IncGC)与JRockit的确定性垃圾收集相比较。

　　结果显示，要达到较短且稳定的响应时间，除了服务器JVM外，还有必要在客户端使用DetGC选项。如果使用的是分布于多台机器上的低负载客户端，而不是在单个机器上的高负载客户端（在实际应用中，这是更常见的情况），那么这个要求就可能不是必需的了。

中间的二十分钟、两台机器的基准测试

　　此外，我们还在JRockit上执行了一系列二十分钟的伸缩测试，以确定在实现高吞吐量而不影响响应时间的情况下的最大并发客户端线程数。在这一阶段，报告了所有结果，只除了每次运行最初60秒（即，ramp-up时间）的数据。

　　下图说明了来自详细的基准测试图表中的详细图表的结果。

图1: 吞吐量和响应时间的最优值

　　对于基准测试来说，结果显示，8个线程是最优的：总的吞吐量为1230个操作/秒，在50毫秒中有99.98%的响应。32个线程时达到了最高吞吐量（1460个操作/秒），但代价是牺牲了响应时间：在50毫秒中只有95.72%的响应。关于这些测试的详细图表，请查看二十分钟伸缩测试。

扩展的两小时、两台机器基准测试

　　最后，我们使用从前面的测试中确定的最优客户端线程数（8个）执行了三次两个小时、两台机器的测试。

　　结果显示，采用DetGC的JRockit在吞吐量和延迟方面都要比采用IncGC的Sun JVM执行得好。JRockit要比Sun JVM快7%，而且Sun JVM大于50 ms延迟的操作百分比是JRockit的5倍高。此外，没有采用DetGC时，JRockit所报告的GC暂停时间高达275毫秒；但是使用了DetGC之后，JRockit所报告的最大GC暂停时间大约为30毫秒，降低了很多（请参见下面的GC暂停时间图表）。

　　下面的两个图表演示了WLRT JRockit JVM与Sun JVM的区别。第一个图表概述了在一个两小时周期中WLRT JRockit上的Trader性能，第二个图表则是Sun JVM上的。每个图表中的顶部黑线显示对应于右侧的标度的吞吐量（越高越好）。底部的红、蓝线则显示对应于右侧的标度的应用程序响应时间（越低越好）。

图2: 两小时基准测试中采用JRockit DetGC所得到的性能

图3: 两小时基准测试中采用Sun IncGC所得到的性能

　　详细的基准测试图表部分提供了这些测试的详细图表。

Trader示例的详细描述

　　Trader示例包括一个多线程的Jython客户端，它使用服务器端J2EE MDB执行请求/响应风格的JMS消息传递。在适当的地方利用Java Spring Framework。服务器端的代码实现了一个股票价格缓存、一个股票价格更新服务、一个股票报价服务。包含示例的基准测试框架是Grinder Java Load Testing Framework。分析和图示基准测试输出以及冗长的JVM GC日志记录的输出的程序也包括在内。

调优Trader示例

　　将下面的调优指导原则应用于Trader示例，以便更好地服从编程最佳实践，提高吞吐量，降低延迟，并简化该应用程序以进行基准测试。综合起来，这些指导原则使吞吐量提高了10多倍，将延迟降低了90%还多，并使得基准测试可以数小时地以稳定速率运行。

对JMS资源进行缓存或入池以重用

　　客户端应用程序和服务器MDB代码被增强以缓存重量级的JMS对象进行重用（JMS连接、会话、生产者、消费者以及临时目的地），而不是对每个消息都打开并关闭它们一次。这是一则标准的最佳实践，是实现连贯的短响应时间所必需的。

在客户端应用确定性垃圾收集

　　要实现较短且稳定的响应时间，除了服务器JVM外，还有必要在客户端使用DetGC选项。如果使用的是分布于多台机器上的低负载客户端，而不是在单个机器上的高负载客户端（在实际应用中，这是更常见的情况），那么这个要求就可能不是必需的了。

将JMS最大消息管道调整为1

　　对定制的JMS连接工厂进行调整，将用于服务器与消费者之间的活动消息的消息管道大小限定为1（通过MessagesMaximum属性）。MDB和客户端都被更改为指向这些定制工厂。根据应用程序的不同，这可以提高响应时间，因为它对延迟的影响要比对吞吐量大。

调优客户端和服务器线程池大小以及MDB并发数

　　为了确保MDB和客户端有足够的线程进行异步消息处理，客户端线程池被增加为32个线程，为报价bean提供了32个专用服务器线程，并为订单bean也提供了32个专用服务器线程。为了利用专用线程，订单和报价bean的MDB描述符max-beans-in-free-pool设置都被设置为32。

限定服务器JVM内存

　　如果Java堆大小设置得过高，确定性GC引擎就可能长期推迟运行GC，从而可能造成较长的GC暂停时间。在稍后的JRockit版本中，这一问题已经得以解决。一个应急方案是在JRockit上配置较低的GC Trigger，但是对于Trader来说，我们选择将为服务器JVM所配置的内存容量限定为256MB。

使用仿真资源管理器替换数据库

　　对于基准测试，用启用仿真XA资源管理器的调用来替换对数据库的调用。这仿真了记录订单到数据库的延迟以及两阶段事务的开销。这也解决了数据库表过大或不同的测试中数据库性能不可重复的潜在问题。

检查JRA配置文件(JRockit Analyzer Profile)以及WebLogic统计信息

　　在定位需要缓存的资源以及内存泄漏时，下面的3个工具会非常有用：

• Runtime Analyzer (JRA)——一个随需应变的动态记录器，它生成关于正在运行的JVM和应用程序的详细记录。随后可以使用JRA应用程序对已记录的信息进行脱机分析。已记录的数据包括对方法和锁定的分析，以及垃圾收集统计信息、优化决策和对象统计信息。
• 针对JMS、事务和存储区持久化的WebLogic JMX统计信息。

避免对运行中基准测试的干扰

　　既然这些基准测试旨在度量最大延迟，所以确保没有与基准测试不相关的进程对其产生干扰就显得愈发重要了。此类处理工作可能不会明显影响吞吐量，但是很可能会干扰响应时间的度量。因此，要确保没有处于活动的登录状态的用户，禁用病毒检查程序，等等。

基准测试环境

　　下面我们来看一下基准测试环境的一些细节。

硬件和操作系统（两台机器）

　　单个机器的基准测试在同一台Dell 6650上运行服务器和客户端。两台机器的基准测试则在一台HP DL380上运行服务器，而在另一台Dell 6650上运行客户端。HP DL380的磁盘硬件要快得多，这加快了事务性和持久性消息处理操作。

• Dell 6650
  • 4-CPU Xeon 3.0 GHz
  • 8 GB的可用RAM
  • 操作系统：Win2003 EE
• HP DL380
  • 2-CPU Xeon EM64T 3.6Ghz，超线程，1Mb L2 Cache
  • 3.5 GB的可用RAM（安装时为4GB）
  • 6-15,000 RPM 36Gb磁盘驱动器，具有电池支持的缓存
  • 4个逻辑盘，其中的2个逻辑盘是放到2个物理盘上的
  • 操作系统：WinSvr2003SE
• 网络
• 计算机是通过一个高速交换机连接的，每台机器到交换机都具有专用的吉比特以太网连接。

软件版本

WebLogic Server配置要点

• File store write-policy = Direct-Write（默认）
• JMS Connection Factory MessagesMaximum = 1（默认是10），对所有的JMS消费者
• Threading = 默认的self-tuning模式，除了对MDB
• 专用的执行队列，64个用于MDB的线程
• Order MDB max-beans-in-free-pool = initial-beans-in-free-pool = 32
• Quote MDB max-beans-in-free-pool = initial-beans-in-free-pool = 32
• JMS服务器具有一个用于订单的队列和一个用于报价的队列

JVM配置

详细的基准测试图表

　　本部分的图表图解了许多运行在不同的时间周期下、采用不同的垃圾收集和线程配置的Trader基准测试。

二十分钟伸缩运行

　　下面的直方图展示了使用JRockit DetGC时，对于不同的延迟，所得到的Trader总操作数，最初是8个线程，然后是64个线程。

图4: 二十分钟基准测试下的不同延迟，使用JRockit DetGC，8个线程

图5: 二十分钟基准测试下的不同延迟，使用JRockit DetGC，64个线程

　　下面的图表对应于前面的JRockit DetGC直方图。第一个图表概述了JRockit DetGC下的Trader性能，使用8个线程；第二个也是如此，只是使用了64个线程。每个图表中的顶部黑线显示对应于右侧的标度的吞吐量（越高越好）。底部的红、蓝线则显示对应于右侧的标度的应用程序响应时间（越低越好）。

图6: 二十分钟基准测试下的性能，使用JRockit DetGC，8个线程

图7: 二十分钟基准测试下的性能，使用JRockit DetGC，64个线程

两小时基准测试运行

　　下面的图表演示了在两小时基准测试中，WLRT JRockit JVM与Sun JVM的区别。同样，每个图表中的顶部黑线显示对应于右侧的标度的吞吐量，而底部的红、蓝线则显示对应于右侧的标度的应用程序响应时间（越低越好）。

图8: 两小时基准测试下的性能，使用无DetGC的JRockit，8个线程

图9: 两小时基准测试下的性能，使用Sun IncGC，8个线程

图10: 两小时基准测试下的性能，使用JRockit DetGC，8个线程

　　下面的3个直方图展示了使用JRockit DetGC、Sun IncGC以及无DetGC的JRockit时，对于不同的延迟，所得到的Trader总操作数，全都是使用8个线程.

图11: 两小时基准测试下的不同延迟，使用无DetGC的JRockit，8个线程

图12: 两小时基准测试下的不同延迟，使用Sun IncGC，8个线程

图13: 两小时基准测试下的不同延迟，使用JRockit DetGC，8个线程

有无确定性GC的暂停时间比较

　　下面的两个图表展示了由冗长的JRockit GC输出所报告的GC暂停时间。

图14: 禁用了JRockit DetGC的基准测试下的GC暂停时间高达275毫秒

图15: 在客户端和服务器都使用JRockit DetGC的基准测试下的最大GC暂停时间只有30毫秒

结束语

　　基准测试结果显示，采用DetGC的WLRT 1.0 JRockit JVM在吞吐量和延迟方面都要比采用IncGC的Sun JVM以及无DetGC的JRockit JVM执行得好。实际上，采用JRockit DetGC的WLRT能够在维持较高的吞吐量的同时极大地降低延迟。

　　此外，没有采用DetGC时，JRockit所报告的GC暂停时间高达275毫秒；但是使用了DetGC之后，JRockit所报告的最大GC暂停时间大约为30毫秒，降低了很多。

参考资料

• WebLogic Real Time下载页面
• WebLogic Real Time 1.0文档
• Spring Open Source Framework Support 1.2.6下载页面
• Trader所使用的Spring Framework
• Trader所使用的Grinder Java Load Testing Framework
• Jython脚本编写语言——Java中的Python，Grinder用它来运行Trader客户端
• Trader用于消息内容的FixML金融协议XML模式
• Trader用于操纵FixML的XMLBean XML java库
• Trader所使用的JFreeChart开源图表库

原文出处:http://dev2dev.bea.com/pub/a/2006/04/real-time-performance.html

您对本文的评价
您对这篇文章的看法如何?
太棒了！5分 不错啊 4分 一般般 3分 有待提高 2分 不好 1分