面向消息的中间件（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）消息传递机制。被强调的特性和服务应该根据它们在现实系统中的作用被赋予不同的重要性。

定义工作负荷事务组合时必须考虑以下几点：

• 事务消息和非事务消息；
• 持久消息和非持久消息；
• 不同的消息类型，如TextMessages、ObjectMessages、StreamMessages和MapMessages；
• 不同大小（小，中，大）的消息；
• P2P和pub/sub通信；
• 一对一、一对多和多对多交互；
• 长期和非长期订阅；
• 消息生产者与消息消费者的比例。

第三，工作负荷应该专注于测试MOM服务器的软硬件组件的性能和可伸缩性。它应该最大程度地降低对在所选应用场景经常使用的其他组件和服务造成的影响。例如，如果数据库用于存储业务数据和管理应用程序的状态，那么以使用其他基准测试工具（如ECperf）显示的经验来看，它就很容易地成为基准测试工具的限制因素。因此，SPECjms2007的工作负荷不能有任何内在的可伸缩性的限制。用户应该能够根据增加接收方（队列和主题）的数目和到达接收方的消息量来扩展工作负荷。

通过生成和发布标准结果来实现营销目的的结果仅仅是SPECjms2007的一种应用场景。在使用基准测试工具时，许多用户将会对调整和优化他们的平台或分析某些特定MOM特性的性能感兴趣。在科研机构中，有些用户为了研究的目的而使用基准测试工具，例如，某些用户可能是因为对评估用于构建高性能MOM服务器的新方法和新技术的性能和可伸缩性感兴趣，而使用了此软件。所有的这些应用场景都有一个共同的要求，即基准测试工具的框架允许用户去精确地配置将要生成的工作负荷和事务组合。提供这种可配置性是一个极大的挑战，因为它需要以这样的一种方式来设计和实现交互，即某用户可以根据自己所期望的事务组合以不同的结合方式来运行它们。

工作负荷场景

SPECjms2007选择的工作负荷场景以超市公司的供应链为模型，涉及的参与者包括超市公司、商店、配送中心和供应商。如图1所示，该场景为定义用于强调MOM服务器提供的不同功能性子集的交互提供了良好的基础，如不同的消息类型、P2P和pub/sub通信。此外，它还支持通过自然的方式扩展工作负荷，如扩展超市数量和每个超市销售的产品数目。

现在我们来进一步研究场景中的参与者。

图1：业务场景——超市供应链

公司总部

公司总部（HQ）负责管理公司的财务审计、超市的货物信息和产品销售价格，以及监控货物和货币在供应链中的流动情况。

配送中心

配送中心（DC）供应货物给超市。每个配送中心负责一定区域内的超市。配送中心的货物由外部供应商供应。配送中心参与以下活动：从超市获取订单，从供应商处订购货物，送货到超市，以及向公司总部上交销售统计表（比如说，用于数据挖掘）。

超市

超市（SM）销售货物给消费者。该场景专注于超市的库存管理，包括仓库管理。有些超市比较小，所以它们没有足够的空间来存放所有产品；有些超市可能专门销售部分产品，如特定类型的食物。我们假定每个超市都有专门的配送中心为其送货。

供应商

供应商发货给超市公司的配送中心。不同的供应商负责发送不同的产品，它们根据超市公司的订单发货。也就是说，它们必需先从超市公司获得订单，然后根据订单发货。

建立的交互模型

SPECjms2007为超市中供应链中的参与者建立了七种交互模型：

1. SM和对应DC之间的订购／发货处理
2. DC和SP间的订购／发货处理
3. 价格更新
4. 库存管理
5. 销售统计数据收集
6. 产品发布
7. 信用卡活动表

让我们来仔细研究一下这些交互。

交互１：SM和DC之间的订购／发货处理

此交互测试SM和DC之间的持久性P2P消息传递。当SM的库存不多时，便会触发此交互，SM必须从DC处订货来填补库存。下面是具体步骤，如图2所示：

1. SM发送订单给DC。
2. DC给SM发送收到订单的确认信息，并向其发出所订购的货物。
3. 当货物从DC库存发出时，需通过RFID阅读程序进行登记。
4. DC发送交易信息（销售统计数据）给HQ；
5. SM收到货物后，要先将货物通过RFID阅读程序登记，然后存入SM库存；
6. SM向DC发送收到货物的确认信息。

图２：交互１——ＳＭ和ＤＣ之间的通信

交互2：DC和SP间的订货／发货处理

此交互测试DC和SP之间的持久性P2P和pub/sub消息传递。当DC的库存不多的时候，便会触发此交互，DC必须从SP处订货来填补库存。下面是具体步骤，如图3所示：

1. DC发送请求给所有可以提供其需要订购的货物种类的SP，要求他们报价。
2. 可以发货的SP发送报价信息给DC。
3. 基于这些报价，DC选择一个SP，向其发送订单。
4. SP发送收到订单的确认信息给DC ，并开发票给HQ，然后发货给DC。
5. DC收到货物之后，要先通过RFID 阅读机登记，然后进入其库存。
6. DC发送收到货物的确认信息给SP。
7. DC发送交易统计信息给HQ。

图3：交互1——SP和DC之间的通信

交互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消息传递。

基准测试实现

作为SPECjms2007基准测试工具的一部分，前面提到的工作负荷场景已经得以实现，现在我们将简要讨论一下具体的实现方法。

事件处理程序和代理

SPECjms2007是作为java应用程序实现的，它由横跨一组客户机节点的多个JVM和线程组成。每个接收方（队列或主题）都通过一个单独的Java类，即事件处理程序（Event Handler，EH），封装应用程序逻辑，执行逻辑将处理发送给接收方的消息。当新消息到来时，事件处理程序登记为队列/主题的监听程序并接收从消息传递基础架构反馈的信息。

为了实现最佳的性能和可伸缩性，在各线程中执行的每个事件处理程序都可存在多个实例，并且它们可以分布在多个物理节点上。事件处理程序可以根据它们在业务场景中的物理位置（如HQ、SM、DC和SP）来分组。

除事件处理程序之外，针对每个物理位置，还可以通过运行一组线程来驱动在该物理位置上逻辑启动的基准测试交互，这就是所谓的驱动线程。所有关于特定物理位置的事件处理程序和驱动线程的集合叫做代理。例如，每个DC代理机构由DC内发送往不同接收方的一组事件处理程序和用来驱动交互2的一组驱动线程组成，而交互2是DC作为逻辑起点来进行交互的唯一的交互。

工作负荷的可配置性

SPECjms2007的另一个重要目标就是为MOM服务器的性能分析提供一个灵活的框架，此框架允许用户根据自己的需求配置和自定义工作负荷。为了实现此目标，交互可以按照以下方式来实现，即用户可以根据所需的事务组合以不同的组合方式来运行交互。要实现可配置性需遵循以下几点：

• 接收方（队列和主题）的数目和类型；
• 某个接收方的通信量；
• 消息类型组合；
• 消息大小组合；
• 消息生产者和消费者的数目。

SPECjms2007提供了三种构造工作负荷的方式：水平方式、垂直方式和自由方式。后面两种方式表示工作负荷的拓扑结构，它们对应于三种不同的模式，即运行提供了不同程度的可配置性的基准测试工具的三种模式。

水平和垂直拓扑结构代表扩展超市供应链场景的两种策略，第一种策略是通过增加物理位置的数目来实现，第二种策略是通过增加每个物理位置的通信量来实现。水平拓扑结构的作用是测试系统在接收方数量不断增加的情况下的处理能力。因此，工作负荷因物理位置（SM、DC等）的数量增加而得以扩充，而每个位置的通信量却仍然保持不变。

另一方面，垂直拓扑结构的作用是测试系统在一组固定接收方的通信量不断增长的情况下的处理能力。因此，它使用一组固定的物理位置，并通过增加交互的运行频率来扩展工作负荷。最后，自由拓扑结构允许用户将SPECjms2007的七种交互作为构建块来设计自己的工作负荷场景，此场景可以通过增加物理位置的数目及/或增加交互运行的速度，以一种自由的方式来扩展工作负荷。表1显示了三种拓扑结构中可以配置的工作负荷参数，如下所示：

在水平和垂直的拓扑结构中，只可以对上面的个别参数进行设置，而在自由拓扑结构中，可以对所有的参数进行设置。更为重要的是，用户可以根据其需求选择性地关闭交互或改变它们的运行频率来形成工作负荷。同时，在使用水平或垂直的拓扑结构时，基准测试中的交互将根据它们在现实应用场景中的相互依赖关系而彼此关联。

工作负荷特征

在第4期European Performance Engineering Workshop（EPEW-2007）学报上发表的《Workload Characterization of the SPECjms2007 Benchmark》论文提供了SPECjms2007的全面的工作负荷特征。衡量基准测试工作负荷的指标包括接收方（队列和主题）的数量和类型、交互组合、消息类型、消息大小和消息交付模式。表2详细列出了在各种交互中使用的不同消息类型和接收方。

论文提供了详细消息吞吐量分析，主要目的有二：其一，通过使用提供的信息，用户可以组合工作负荷配置（根据位置的数目和交互率），这种配置强调消息在特定缩放条件下具体类型。这允许用户使用SPECjms2007交互作为构建块来创建自定义工作负荷。一个非常基础的例子：当订阅者数量不断增加时，用户可能对评估非持久性pub/sub消息传递的性能和可伸缩性感兴趣。在这种情况下，当SM数量不断增加时，交互6和交互7就需要组合起来使用。其二，在每个基础位置的通信量的特征可以帮助用户去发现处于不同位置的代理机构的最佳部署布局，这样，负荷将平均分布在各客户节点中，且不会使客户端成为瓶颈。这对于消息传递基准测试极为重要，因为服务器在交互过程中充当调停者的角色，并且需要在客户端上处理大量任务。

水平拓扑结构

如前所述，水平拓扑结构的目标是测试系统在接收方数量不断增加的情况下的处理能力。为此，工作负荷将通过增加物理位置（SM、DC等）的数量而得以扩展，而每个位置的通信量却仍然保持不变。在运行基准测试之前，必须设置BASE扩展参数。当BASE增加时，全部消息的吞吐率将上升直至系统饱和。为了使运行有效（通过），所有的队列都必须是稳定的，且90％的传送时间不能超过5秒。

有效水平运行的基准度量指标称作SPECjms2007@Horizontal，它等于运行基准测试的BASE参数值。用户期望使用不断增加的BASE值运行多次测试，并且直到BASE值达到最大时，此运行仍然有效。后者将作为SPEC发布的正式结果被提交。

图4：水平拓扑结构的位置

图4显示了当BASE参数增加时，每种类型的位置数量是如何扩展的。由于参与者发起交互的频率是固定的，因此每个位置（接收方）的通信量保持不变。交互的相对重要性是根据详细的超市供应链的业务模型的来设置的，此模型捕捉了交互的相关性。该模型有若干个输入参数（如产品类型的总数、超市的规模和每周销售产品平均数量），在选择输入参数值时应尽可能实现全面的目标消息传递组合：

• 50%的P2P消息和50%的pub/sub消息；
• 50%的P2P持久性消息和50%的非持久性消息；
• 25%的持久性pub/sub消息和75%的非持久性消息。

目标是使P2P通信和pub/sub消息传递具有同样的重要性。在各组内，持久性通信和非持久性通信的目标相对重要性是根据在现实的应用中这些通信类型的相关应用来设置的。图5显示了在水平拓扑结构中的消息组合。当扩展工作负荷时，不同消息类型的比例保持不变。在不同交互中用到的消息大小的选定是为了能够反映在现实的MOM应用程序中典型的消息大小。由于传送机制的非耦合性，所以Pub/sub消息通常比P2P消息小。

图5：水平拓扑结构消息组合

垂直拓扑结构

垂直拓扑结构使用一组固定的物理位置，并通过增加执行交互的频率来扩展工作负荷。与水平拓扑结构一样，它使用参数BASE作为比例因子，用户将根据需要扩展工作负荷，直到BASE达到最高，且仍然能够满足一次有效运行。SPECjms2007@Vertical是垂直拓扑结构的基准度量指标。同样，交互的相对重要性是根据供应链场景的业务模型来设置的。然而，和水平拓扑结构不同，垂直拓扑结构强调P2P消息传递，该消息传递占80%的通信量。

其目的是测试系统在接收方通信量不断增加时并行处理消息的能力。对于MOM服务器在此方面的性能，P2P消息传递（队列）要比pub/sub消息传递具有更为密切的相关性。在pub/sub消息传递中，根据用户处理接收消息的速度来看，消息的吞吐量在本质上是有限的。图6显示了垂直拓扑结构实现的消息组合。同样，在扩展工作负荷时，消息组合仍然保持不变，这是预期的行为。

图6：垂直拓扑消息组合

结束语

SPECjms2007是一款灵活且稳健的工具，它能够对MOM服务器的性能进行深入评估。该基准测试工具允许用户根据自己的需要自定义工作负荷，通过配置工作负荷来强调MOM基础架构的特定特性，这在某种程度上类似于一个特定的目标用户的工作负荷。然而，为了利用这一点，用户需要了解工作负荷的构成方式和各组件所测试的性能方面。在本文中，我们首先介绍了SPECjms2007建立的业务场景和工作负荷模型，然后探究了基准测试的设计和内部架构。通过研究交互、消息组合和它们的扩展方式，我们呈现了工作负荷的特征。一方面，由于此特征帮助用户增强了对SPECjms2007工作负荷的深入理解，所以他们能正确地解释基准测试工具的输出结果。另一方面，根据这些信息，用户可以根据他们的需要来设计工作负荷。

SPECjms2007为测试MOM服务器的性能和可伸缩性提供了一个有代表性的工作负荷场景。它有以下用途：

• 比较各种不同的MOM平台（包括硬件和软件）在性能和可伸缩性方面的差异；
• 研究不同配置选择和调整MOM平台参数对系统总体性能的影响；
• 重点测试MOM平台并分析其潜在的瓶颈；
• 构建自定义工作负荷，强调MOM性能的特定方面。

禁用约束:
ALTER TABLE table_name DISABLE CONSTRAINT constraint_name;
 或
ALTER TABLE policies DISABLE CONSTRAINT chk_gender
 

重新启用约束：
ALTER TABLE policies ENABLE CONSTRAINT chk_gender
 

删除约束:
ALTER TABLE table_name DROP CONSTRAINT constraint_name
或
ALTER TABLE policies DROP CONSTRAINT chk_gender;

更改表的约束 
CONSTRAINT [constraint_name] CHECK (condition);

http://www.knowsky.com/389195.html