主题
企业架构
SPECJMS2007：针对面向消息中间件的新型基准测试工具和性能分析框架by Samuel Kounev and Kai Sachs
介绍面向消息的中间件（Message-oriented middleware，MOM）作为一种开放技术，在当今的事件驱动型应用程序领域，如股票交易、基于事件的供应链管理、空中交通管制和在线拍卖等领域，得到了日益广泛的应用。此外，发布订阅范例在许多新软件架构和和技术领域中都作为构建块使用，如企业服务总线（Enterprise Service Bus，ESB）、企业应用集成（Enterprise Application Integration，EAI）、面向服务的架构（Service-Oriented Architecture，SOA）和事件驱动架构（Event-Driven Architecture，EDA）。然而，新型的消息传递应用程序也带来了一系列严重的性能和可伸缩性挑战。例如，基于RFID技术的下一代事件驱动供应链管理将在很大程度上依赖于可伸缩且高效的后台系统，以支持处理获取的实时数据并与企业应用程序和业务流程集成。一些大型零售商，如Wal-Mart、Metro或Tesco，都希望其吞吐率能够达到6000亿消息/年。要在行业中成功应用这些软件，用于处理这些消息的底层MOM平台的性能和可伸缩性将是至关重要的。 为了保证应用程序能够满足服务质量（Quality of Service，QoS）的需求，使用基准测试工具检测和验证开发应用程序平台的性能和可伸缩性是必备之需。虽然行业中出现了一些专门针对MOM服务器的基准测试工具（如 SonicMQ Test Harness, IBM 的 Performance Harness），并且支持性能测试和产品比较，但它们未能为性能比较提供公平竞争的场地。原因在于，其中大多数软件都使用人工虚拟的负荷，而这恰恰无法反映任何真实的应用程序场景。此外，它们往往过分强调单独且孤立的MOM特性，而没有提供一个全面且有代表性的工作负荷，以评估整体MOM服务器的性能。 为了解决这些问题，标准性能评估机构（SPEC）于2005年9月发起了一个项目，目的是开发一个标准的基准测试工具，用于评估MOM产品的性能和可伸缩性。这款新的基准测试工具就是SPECjms2007，它由SPEG的OSG-java分委员会携Technische Universität Darmstadt、IBM、Sun、Oracle、BEA、Sybase和Apache共同开发。SPECjms2007通过所有主要MOM厂商支持的 JMS (Java Message Service)标准接口来测试消息传递产品。 需求和目标 SPECjms2007基准测试工具的目的是为检测和评估基于JMS的MOM平台的性能和可伸缩性提供一个标准的工作负荷和规则。为了实现此目的，SPECjms2007的工作负荷必须满足以下几个重要条件。首先，它必须以有代表性的工作负荷场景为基础，这个场景能反映平台服务在现实系统中的实现方式。在基准测试应用场景中，不同方传送和接收的通信方式和消息类型应该代表一个典型的事务组合。目标是允许用户将观测到的行为与他们自己的应用程序和环境联系起来。其次，工作负荷应该是全面的，因为它应该测试MOM应用程序中使用的所有平台特性，包括P2P和发布/订阅（pub/sub）消息传递机制。被强调的特性和服务应该根据它们在现实系统中的作用被赋予不同的重要性。 定义工作负荷事务组合时必须考虑以下几点：
第三，工作负荷应该专注于测试MOM服务器的软硬件组件的性能和可伸缩性。它应该最大程度地降低对在所选应用场景经常使用的其他组件和服务造成的影响。例如，如果数据库用于存储业务数据和管理应用程序的状态，那么以使用其他基准测试工具（如ECperf）显示的经验来看，它就很容易地成为基准测试工具的限制因素。因此，SPECjms2007的工作负荷不能有任何内在的可伸缩性的限制。用户应该能够根据增加接收方（队列和主题）的数目和到达接收方的消息量来扩展工作负荷。 通过生成和发布标准结果来实现营销目的的结果仅仅是SPECjms2007的一种应用场景。在使用基准测试工具时，许多用户将会对调整和优化他们的平台或分析某些特定MOM特性的性能感兴趣。在科研机构中，有些用户为了研究的目的而使用基准测试工具，例如，某些用户可能是因为对评估用于构建高性能MOM服务器的新方法和新技术的性能和可伸缩性感兴趣，而使用了此软件。所有的这些应用场景都有一个共同的要求，即基准测试工具的框架允许用户去精确地配置将要生成的工作负荷和事务组合。提供这种可配置性是一个极大的挑战，因为它需要以这样的一种方式来设计和实现交互，即某用户可以根据自己所期望的事务组合以不同的结合方式来运行它们。 工作负荷场景 SPECjms2007选择的工作负荷场景以超市公司的供应链为模型，涉及的参与者包括超市公司、商店、配送中心和供应商。如图1所示，该场景为定义用于强调MOM服务器提供的不同功能性子集的交互提供了良好的基础，如不同的消息类型、P2P和pub/sub通信。此外，它还支持通过自然的方式扩展工作负荷，如扩展超市数量和每个超市销售的产品数目。 现在我们来进一步研究场景中的参与者。 公司总部 公司总部（HQ）负责管理公司的财务审计、超市的货物信息和产品销售价格，以及监控货物和货币在供应链中的流动情况。 配送中心 配送中心（DC）供应货物给超市。每个配送中心负责一定区域内的超市。配送中心的货物由外部供应商供应。配送中心参与以下活动：从超市获取订单，从供应商处订购货物，送货到超市，以及向公司总部上交销售统计表（比如说，用于数据挖掘）。 超市 超市（SM）销售货物给消费者。该场景专注于超市的库存管理，包括仓库管理。有些超市比较小，所以它们没有足够的空间来存放所有产品；有些超市可能专门销售部分产品，如特定类型的食物。我们假定每个超市都有专门的配送中心为其送货。 供应商 供应商发货给超市公司的配送中心。不同的供应商负责发送不同的产品，它们根据超市公司的订单发货。也就是说，它们必需先从超市公司获得订单，然后根据订单发货。 建立的交互模型 SPECjms2007为超市中供应链中的参与者建立了七种交互模型：
让我们来仔细研究一下这些交互。 交互１：SM和DC之间的订购／发货处理此交互测试SM和DC之间的持久性P2P消息传递。当SM的库存不多时，便会触发此交互，SM必须从DC处订货来填补库存。下面是具体步骤，如图2所示：
交互2：DC和SP间的订货／发货处理此交互测试DC和SP之间的持久性P2P和pub/sub消息传递。当DC的库存不多的时候，便会触发此交互，DC必须从SP处订货来填补库存。下面是具体步骤，如图3所示：
交互3：价格更新此交互测试HQ和SM之间的持久性pub/sub消息传递。当公司管理部门的销售价格有变动时，便会触发此交互。为了实现这种通信，HQ需发送价格信息给SM。 交互4：SM库存管理这个交互是指SM内部的持久性P2P消息传递。当SM的仓库出货或填充货物时，便会触发此交互。当货物通过RFID阅读程序登记后，当地库存的应用程序会通知以便货物的详细目录能够得到及时地更新。需要注意的是新进的货物是另一个交互（交互1）的一部分，这里不做考虑。 交互5：销售统计数据收集此交互测试SM和HQ之间的非持久性P2P消息传递。当SM发送销售统计信息给HQ时，便会触发此交互。HQ可以使用此数据作为数据挖掘的基础，以便于研究消费者的行为并为市场提供有用的信息。例如，这些信息可用于制订特价优惠或商品折扣。 交互6：新产品发布此交互测试SM和HQ之间的非持久性pub/sub消息传递。当公司管理部门发布新产品时，便会触发此交互。为了建立通信，HQ需要将产品信息发送给销售各种产品（如食品、计算机和mp3播放器）的SM。 交互7：信用卡活动表此交互测试HQ和SM之间的非持久性pub/sub消息传递。当HQ发送信用卡活动表给SM（此表每隔一小时完成一次，并根据需要及时更新）时，便会触发此交互。此交互过去用于执行非持久性pub/sub消息传递。 This interaction exercises non-persistent, non-durable pub/sub messaging between the HQ and the SMs. The interaction is triggered when the HQ sends credit card hot lists to the SMs (complete list once every hour and incremental updates as required). This interaction is used to exercise non-durable, non-persistent pub/sub messaging.
|
Printer View