z / OS上的WebSphere Application Server上的Java Messaging Service的性能调整

本文介绍了如何在WebSphere Application Server上运行JMS应用程序时调整现有的z / OS系统以获得最佳性能。 尽管本文的大多数调优技巧也适用于JMS Publish-Subscribe案例，但本文将以JMS单队列点对点方案为例。

您将使用用于z / OS的WebSphere Application Server V6.0.2和用于z / OS的WebSphere MQ V5.3.1（以下称为WebSphere MQ）作为参考产品。 您还将使用JMS消息驱动bean（MDB），因为它们的调整与服务器调整过程紧密相关。

在使用默认的嵌入式消息传递提供程序（称为WebSphere Platform Messaging）运行以及使用外部消息传递提供程序（称为WebSphere MQ）时，您将了解两种情况的调优过程。

本文面向的是经验丰富的z / OS用户，他们对WebSphere Application Server有一定的了解（不一定在z / OS平台上），并且了解WebSphere MQ的基本概念（请参阅MP16：WebSphere MQ for z / OS）。 -容量规划和调整 ）。

本文假定：

• 您可以访问已经包含WebSphere Application Server和WebSphere MQ实例的z / OS系统。 本文中的示例涉及特定的安装。 因此，本文档中使用的目录，数据集和进程的名称可能不适用于您的系统。 本文概括了可能的情况，或警告您可能会出现不一致的情况。
• 您为WebSphere Application Server安装了一个服务器。 如果使用的是WebSphere Application Server网络部署，则应始终参考包含消息传递资源已本地化的应用程序服务器的节点的安装结构。
• 您可以访问ISPF会话，并且可以telnet（或rlogin）到同一系统。 telnet访问不是强制性的，因为您始终可以在ISPF会话中使用TSO MVS™命令来运行UNIX Shell脚本。 或者，您可以编写一个JCL作业来为您完成此任务。

为WebSphere Platform Messaging配置WebSphere Application Server

现在称为WebSphere Platform Messaging的WebSphere Application Server JMS引擎现在是100％Java，并提供了企业服务总线（ESB）体系结构的实现。 WebSphere Platform Messaging中的JMS支持是更通用的ESB功能的特例。 因此，您将需要执行一些额外的配置步骤，以使基本的JMS点对点方案能够正常工作。

巴士和目的地

程序员通常将队列和主题视为JMS应用程序的最简单实体，并且只是可变深度的容器。 实际上，在大多数情况下，目标的选择和配置（队列或主题的通用术语）对于性能良好的系统至关重要。 对于WebSphere Platform Messaging（其总线体系结构严重依赖于快速且相互连接的目的地）的WebSphere Platform Messaging而言，此选择甚至更为重要。 本节介绍了创建总线，目的地和您可以选择的所有性能选项所需的步骤。

假设您要创建一个位于Server1中的JNDI名称为Q1的队列：

1. 首先，创建一个Bus对象。
   1. 从WebSphere管理控制台的左侧菜单中，选择服务集成 => 总线 。 单击New并为其命名，例如BUS1 ，如图1所示。
   2. 现在，您必须做出一个会大大影响性能的选择：是否运行安全总线。 如果您可以在没有安全的情况下生活，那么根据工作负载的类型，速度可能会提高10％-30％。 请记住，WebSphere Application Server还有另外两个安全设置，分别是JVM级别（Java安全）和服务器级别（全局安全）。 迄今为止，安全总线是最昂贵的选择。
   3. 将“ 高消息阈值”参数设置为比在任何给定时间内您的工作负载将交换的消息数量多的消息。 在大多数情况下，默认值50000应该可以接受。
   4. 单击确定并保存。

      图1.总线配置

      
2. 将服务器实例分配给BUS1。
   1. 单击创建的BUS1，然后选择Bus Member => Add 。
   2. 选择服务器单选按钮，然后从下拉菜单中选择合适的服务器实例。
   3. 单击下一步 ，然后单击完成 。 保存。
3. 在BUS1中，定义位于Server1中的名为QD1的队列目标对象。 队列目标定义了队列的物理位置，并且可以承载多个逻辑队列。
   1. 选择新创建的BUS 1，然后在目的地的资源类右侧面板上的目的地 。
   2. 单击新建，然后选择队列作为目的地类型。 输入标识符QD1 。 单击下一步 。
   3. 确保总线成员是您先前定义的成员。 单击下一步=>完成 。 保存一切。
   4. 检查您创建的目的地，并确保在“服务质量”区域中选中了“ 允许生产者覆盖默认可靠性”框。 此设置非常重要，因为您希望自由选择邮件的可靠性设置，而不必使用默认的目的地。
4. 为属于BUS1并位于QD1中的Default Provider创建一个JMS队列资源Q1。
   1. 在WebSphere管理控制台的左侧菜单中，单击资源 。
   2. 展开JMS Providers并选择Default Messaging 。
   3. 在下一个菜单中，在Destinations标题下右侧的JMS Queue上，单击。
   4. 创建一个新队列，将其命名为Q1 （例如，JNDI名称为test/Q1 ）。
   5. 在“连接”部分下，将正确的总线名称选择为BUS1 。 此选择将填充“队列名称”下拉菜单。
   6. 选择QD1作为队列名称。 将其他参数保留为默认值，如图2所示。
   7. 按确定并保存。

图2.队列配置

现在，发送到Q1的消息将在总线BUS1内部流动，到达将消息存储在Server1上的目的地QD1。 使用此配置，服务质量（可靠性）的类型将成为消息的属性，而不是目标中的设置。 这样可以为不同类型的服务重用同一目的地提供更大的灵活性。

下一段描述了选择消息可靠性的机制，您将在其中学习如何调整连接工厂。

连接工厂

在将目的地填充到我们的总线并在特定的服务器实例中将它们本地化之后，您应该为用户应用程序构建入口点。 连接工厂是提供与总线连接的实体。 此连接的特性对于性能至关重要，并且只能在创建连接工厂期间进行设置。

1. 在WebSphere管理控制台的左侧菜单中，单击资源 。
2. 展开JMS Providers并选择Default Messaging 。
3. 在右侧的“连接工厂”下，您有两个可能的选择： JMS连接工厂和JMS队列连接工厂 。 在性能方面没有区别，但是如果有可能使用JMS1.0.2（而不是更通用的JMS1.1规范）开发了客户端应用程序，则应该使用后一个选项。
4. 输入名称 ， JNDI名称和总线名称 。
5. 在“高级消息传递”中，选择“预读” 。 此设置将提高您的消费者客户的性能。

JMS规范描述了两种消息传递类型：持久性消息和非持久性消息。 WebSphere Platform Messaging引入了三种非持久性消息和两种持久性消息：

• 非持久性消息
  • 当消息传递引擎停止或失败时，将尽力而为消息被丢弃。 如果由于系统资源不足而导致发送消息的连接不可用，则消息也可能会被丢弃。 您可以使用此设置达到最佳性能。 如果您有能力在队列已满时丢失消息，则别无所求。
  • 当消息传递引擎停止或出现故障时， Express消息将被丢弃。 如果用于发送邮件的连接不可用，则邮件也可能会被丢弃。 Express通常比尽力而为慢20％，但是它的优点是当队列满时您不会丢失消息。 系统很高兴在数据库中找到一些空间来存放其他消息。 不幸的是，当您的队列将消息泄漏到数据库时，性能会急剧下降，情况会越来越糟。 Express是非持久可靠性设置的默认设置。
  • 当消息传递引擎停止或发生故障时， 可靠的消息将被丢弃，这与Express Service Quality并无太大区别。 Reliable只是在服务器和客户端之间引入了一条额外的确认消息，以确保消息的传递。 与Express相比，预期性能会下降15％-20％。
• 持续性消息
  • 当消息传递引擎发生故障时，可能会丢弃可靠的消息。 服务器接收的每个消息都存储在数据库中，但这是在与接收消息不同的线程上异步执行的。 如果服务器在消息持续存在之前完成操作，则它将丢失。 尽管不是100％安全，但此服务质量允许有效地使用数据库，因为写入是分批完成的。 同样，在同时应用读取和删除操作时会应用多种优化。 可靠是持久性消息的默认设置。
  • 保证的消息将永远不会被丢弃。 当发送操作后生产者应用程序成功返回时，WebSphere Application Server保证消息不会丢失。 您应该对事务使用有保证的持久性。 这是最慢的服务质量，比“可靠持久性”高30-50％。

显然，服务质量的提高与性能的提高相对应。 在zSeries z990服务器中使用1Kb的消息大小进行测量，确保的防弹持久性与轻松的尽力而为之间的差异约为4倍。 随着消息大小的增加，非持久消息传递的性能比持久消息传递的性能下降得更快。

通过连接工厂创建菜单，您可以将两种JMS消息传递类型映射到以上五种类型的WebSphere Platform Messaging服务质量中的任何一种，如图3所示。

图3.服务质量

创建连接工厂后，选择新创建的队列连接工厂，然后单击“附加属性”下的“ 连接池 ”属性。 将参数“ 最大连接数”设置为大于连接到服务器的预期客户端应用程序的数量。

Java堆

启用了WebSphere Platform Messaging的WebSphere Application Server实例在称为区域的三个不同过程之上运行：控制区域（CR），服务方区域（SR）和控制区域附件（CRA）。 每个区域都有其自己的JVM，因此具有独立的配置/调整：

• CR是WebSphere Application Server的核心，并处理所有区域内通信。 CR控制传入消息到多个现有SR的分发。 CR需要少量的代码和很小的堆空间才能运行。 对于CR，请使用256MB或更大的堆大小。
• SR托管在多个JVM中运行的EJB容器进程，以实现可伸缩性。 在消息传递世界中，SR运行MDB。 由于SR占用大量内存，因此请使用512MB或更大的堆大小。
• WebSphere Platform Messaging流程仅在其中运行一个CRA。 CRA有效地负责所有消息传递代码，并且需要大量的堆大小。 使用的堆大小为512MB或更大。

设置区域的堆大小：

1. 从“服务器和应用程序服务器”选择（在WebSphere管理控制台的左侧面板上），选择您的服务器。
2. 在“服务器”右侧选择区域的“服务器基础结构”下，展开“ Java和流程管理”，然后选择“ 流程定义” 。
3. 您应该看到三个过程： Adjunct ， Control和Servant ，分别对应于CRA，CR和SR。 选择要设置其堆大小的进程，然后单击Java虚拟机 。
4. 您将看到几个属性。 将最大堆大小更改为所需的值。 同样，对于CR进程，请考虑至少使用256 MB。 对于SR和CRA进程，至少使用512 MB。

其他调音技巧

接下来的几节描述了WebSphere Application Server的其他优化：

• 痕迹和PMI
• 天体
• 线程池
• 多个仆人地区
• z / OS WLM

痕迹和PMI

WebSphere Application Server带有默认情况下启用的某种级别的跟踪和PMI。 当性能至关重要时，您应该关闭所有级别的跟踪。

禁用z / OS系统的所有子系统组件跟踪。 当已经以超过95％的可用CPU运行时，这特别有用。

ORB设置

在z / OS中，进程间通信利用对象请求代理（ORB）服务。 在ORB服务成为瓶颈的情况下，它有助于通知z / OS系统我们需要更多专用的系统线程。

要更改ORB设置：

1. 从WebSphere管理控制台左侧面板上的“服务器和应用程序服务器”选择中，选择服务器实例。
2. 在“容器服务”下，选择“ ORB服务” 。
3. 在其他属性下，单击z / OS其他设置 。
4. 在工作负载配置文件下拉菜单上，选择LONGWAIT 。 LONGWAIT会将不持久率提高到5％。
5. 为了降低内存利用率，请通过选择“ 按引用传递”来禁用ORB本地副本。 这等效于将以下选项添加到JVM： Dcom.ibm.CORBA.iiop.noLocalCopies=1

线程池

WebSphere Application Server对不同的任务集使用不同的线程池。 由于这个原因，CPU密集和费时的活动通常会发现自己缺少可用的线程来执行，而与此同时，与简单而快速的任务相关联的其他线程池却充满了空闲线程。 为了使系统平衡所需的工作负载类型，应更改不同线程池上的设置。 在某些配置中，开箱即用的值可能不足。

要在WebSphere管理控制台中设置各种线程池：

1. 从左侧面板上的“服务器和应用程序服务器”选择中，选择您的服务器。
2. 在通信下，选择消息传递=>消息侦听器服务 。
3. 在其他属性中，选择“ 线程池”，然后将“ 最大大小”设置为MDB的所有maxConcurrency加上与服务器的JMS客户端连接数之和。
4. 从左侧面板上的“服务器和应用程序服务器”选择中，选择您的服务器。
5. 在其他属性下，选择线程池 。 应该已经定义了三个线程池。
   • 通常所有容器应用程序都共享默认值 。 例如，如果您正在运行多个MDB，则请确保扩展此池。 对于系统中存在的单个MDB，请使用最小大小30和最大大小40。
   • SIBFapThreadPool是服务集成总线FAP出站通道线程池，所有JMS应用程序向服务器发送消息或从服务器使用消息都使用它。 其最大大小的最佳值应为50。
   • WebContainer对普通的JMS应用程序没有任何影响，除非您当然拥有使用JMS或驱动EJB JMS生产者的servlet。 在这种情况下，请再次确保您的最大尺寸大于20。

多个仆人地区

由于消息工作负载中涉及的线程数量众多，因此增加这些线程池并不总是非常有效。 通常，具有100个以上线程的线程池的性能开始下降。 由于过度的同步和锁定，系统本身会变慢。 此时，如果EJB容器变得太忙，则可以运行多个并发SR。

要运行并发SR：

1. 从左侧面板上的“服务器和应用程序服务器”选择中，选择服务器实例
2. 选择Java和进程管理=>服务器实例
3. 您可以选择“ 启用多个实例” ，并将“ 最大实例数”设置为任何值。 理想情况下，您应该在5到10之间选择一个值

z / OS WLM

在消息传递工作负载期间，您应该确定一些进程的优先级。 z / OS WLM是实现该目标的一种方法。 作为消息传递的一般规则，CR和CRA应具有比SR高的优先级（STCFAST）。

配置WebSphere Platform Messaging的默认提供程序

本节介绍了影响嵌入式Java消息传递引擎性能的所有那些设置。 在z / OS系统上，消息传递引擎在其自己的Java虚拟机（通常称为CRA）中执行。 消息传递引擎的两个重要组件在CRA中运行：资源适配器和消息存储。 资源适配器处理MDB。 消息存储负责将持久性消息写入数据库。 对这些组件进行正确的调整通常可以使您获得巨大的性能提升。

调整MDB激活规范

调整MDB并非易事。 MDB是无状态会话Bean，它缺少其主接口或远程接口。 应用程序不能直接调用MDB，而只能通过在MDB正在侦听的队列上发送消息来间接调用MDB。 MDB驻留在EJB容器中，因此它必须通过某种适配器与消息传递世界进行交互。 在z / OS上，容器在与消息传递引擎（CRA）不同的进程（SR）中运行。 连接这两个过程的代码称为资源适配器（在JCA 1.5规范中定义的RA），并且部分存在于SR和CRA中。

要调整资源适配器以获得最佳吞吐量：

1. 在WebSphere管理控制台中，单击资源=>资源适配器。
2. 在资源适配器下，您可以找到MDB用于连接到消息传递引擎的SIB JMS资源适配器。 该适配器定义了一个称为激活规范的对象，该对象充当MDB的连接工厂。
3. 您可以通过单击SIB JMS资源适配器对象右面板中的J2C激活规范来创建激活规范。
4. 按New进入配置屏幕，您可以在其中选择激活规范所引用的JNDI名称。 您可以将JNDI名称保留为空白，并在部署MDB时覆盖该属性。

创建激活规范后，您需要设置一些重要的自定义属性，如图4所示。

图4.激活规范的定制属性

两个最重要的属性是maxBatchSize和maxConcurrency 。

• maxBatchSize设置发送到MDB的单个运行实例的消息批处理的最大大小。 最佳值在5到10之间变化。
• maxConcurrency设置容器中存在的MDB并发实例的最大数量。 maxConcurrency越高，MDB并行消费的消息越多。 我们发现40对于密集消息传递工作负载而言是一个最佳值。
• 重要： maxConcurrency引用单个MDB，而不是指EJB容器中部署的所有MDB的所有实例的总数。 因此，将其设置得太高是危险的。 由于每个MDB实例都在不同的线程上运行，因此并发MDB的数量很可能受到容器线程池的限制，而不是其他线程。

消息引擎数据存储

在WebSphere Platform Messaging中，消息首先以表示队列的结构存储在内存中。 此缓存的大小有限，默认设置可能不足以处理消息密集型工作负载。

对于非持久性消息，缓存大小甚至更为重要，因为满队列通常意味着消息丢失（尽力而为）或性能下降（快速和可靠）。 您可以通过在WebSphere管理控制台中设置一些属性来修改内存高速缓存大小（即队列大小）。

设置队列深度：

1. 转到服务器=>应用程序服务器，然后选择您的服务器实例。
2. 在右侧部分，选择“ 消息传递引擎” ，然后选择您定义的消息引擎。
3. 在其他属性下，单击自定义属性 。 添加以下内容：

   sib.msgstore.cachedDataBufferSize = 40000000
   sib.msgstore.discardableDataBufferSize = 10000000.

图5.消息存储属性

cachedDataBufferSize定义具有非持久性服务质量的消息的深度（以字节为单位）。 discardableDataBufferSize表示持久队列深度。 上述值在1Kb消息的性能基准中表现良好。 消息量较大的工作负载可能需要更高的值。 请记住：尽管这些缓存大小只是从Java堆中获取的，但是当内存不足时，垃圾回收可能会成为一个问题。

使用和调整WebSphere Platform Messaging的另一个重要因素是，当以持久服务质量运行或由于队列已满而发生消息溢出时，将消息写入磁盘的机制。 WebSphere Platform Messaging为此目的使用了一个数据库，并且WebSphere Platform Messaging内部附带的缺省数据库是Cloudscape™。 但是，可以使用其他数据库。

为WebSphere Platform Messaging选择正确的数据库并正确调整数据库可以显着提高性能。

要在WebSphere管理控制台中更改消息引擎的缺省数据库：

1. 为数据库创建JDBC资源。 在WebSphere管理控制台左面板中，选择Resources => JDBC Provider => New。 配置新的提供程序：
   • 数据库类型： DB2
   • 提供程序类型： 通用JDBC驱动程序提供程序
   • 实现类型： 连接池数据源
   • 名称：您的选择
   • 实现类: com.ibm.db2.jcc.DB2ConnectionPoolDataSource
2. 创建JDBC提供程序后，单击它，然后在右面板上选择数据源 。 单击新建以创建数据源。 给它提供一个JNDI名称，稍后将使用它。 确保在“ DB2通用数据源属性”部分中填写正确的值。 例如，我们系统的数据库名称为DSN810P3 ， 驱动程序类型为2。如果未指定，则服务器名称将默认为localhost 。 保存后，单击测试连接 。
3. 单击新创建的数据源，然后在右侧的“其他属性”下选择“ 连接池”属性 。 数据源的连接池参数是非常重要的调整参数。 将“ 最大连接数”设置为大于50的值。您可以使用更大的数量而不会带来负面影响。 在我们的系统中，我们有200个。
4. 在数据源面板的“其他属性”下，确保禁用了与跟踪和跟踪级别相关的“ 自定义”属性 。
5. 选择服务器=>应用程序服务器 ，然后选择成为总线BUS1成员的服务器实例。
6. 在“服务器消息传递”下，选择“ 消息传递引擎” 。
7. 您可能只有一个类型为<host>Node01.<servername>-BUS1 。 单击该消息传递引擎。
8. 在以下屏幕的右侧，选择数据存储 。
9. 将数据源JNDI名称更改为您在上一步中为数据源设置的名称。 您可能需要通过单击J2EE连接器体系结构（J2C）身份验证数据条目来创建新的身份验证别名。 如果使用DB2®，则可以将Schema名称设置为任何名称 。 在图5中，我们使用了IBMWSSIB，它是Cloudscape数据库的默认值。 使用Oracle，必须将Schema名称设置为用于连接数据库的用户名。 您需要重新启动服务器才能使更改生效。

图6. WebSphere Platform Messaging的数据存储

性能测量表明，DB2 v8.1的速度是默认Cloudscape的两倍。 在DB2上，DASD I / O时间是限制因素，任何旨在改进它们的常规调整都将使消息传递性能受益。 在z / OS上调优DB2本身就是一门艺术，并且有大量文档可供参考。

为WebSphere MQ配置WebSphere Application Server

在将WebSphere MQ用作WebSphere Application Server中的外部消息传递提供程序时，您需要使用一些不同的配置步骤来调优系统以获得最佳性能。 但是， Java堆中报告的性能技巧和其他调优技巧也适用于此方案。

创建工厂，队列和侦听器端口

通过适当地调优WebSphere MQ可以最大程度地提高性能，但是接受工厂和目标配置中的所有缺省设置可能会造成多个瓶颈。

要设置JMS点对点方案，在使用MDB时，首先需要定义队列工厂，队列和侦听器端口：

1. 在WebSphere管理控制台中，展开Resources => JMS Providers并单击WebSphere MQ 。
2. 在右侧部分的其他属性下，单击WebSphere MQ队列连接工厂=>新建，然后输入名称和JNDI名称 。 还要输入队列管理器 ， 主机和端口参数。 如果您在同一系统上运行WebSphere MQ，那么队列管理器名称就足够了。 Transport类型参数对性能有很大影响，下一节将对此进行说明。
3. 选择“ 启用MQ连接池” 。 还要检查代码集（或CCSID）是否是队列管理器定义参数列表中使用的代码集。 使用500作为值。
4. 按确定 ，然后按保存 。
5. 创建队列连接工厂后，单击它并在“其他属性”下设置连接池 。 尽管WebSphere MQ在内部池化连接，但是最好将此连接池设置为比缺省值更大的最大值。 根据经验，最大连接值应为在最繁忙的情况下在任何给定时间尝试连接的所有客户端应用程序的总和，包括内部MDB。
6. 以与对队列连接工厂的连接池相同的方式设置会话池 。 这次，您需要计算将有多少个客户端共享一个相同的连接。
7. 在服务器Messaging => Message Listener Service中定义一个监听器端口，如图6所示。为应用程序服务器节点（而不是Deployment Manager节点）定义监听器端口。

图7.消息监听器服务

MDB的onMessage方法在MessageListener线程上执行； MDB实例和侦听器端口池重新使用此线程。 您必须配置此池，即MessageListener 线程池 ，以启用足够的并发性来达到性能要求。 值50应该足够。

图6显示了在哪里可以找到该线程池。

此外，每个侦听器端口都提供一个可配置的属性Maximum Sessions ，该属性限制了该特定侦听器端口的并发性。 “ 最大会话数”属性默认为1，这会阻止在侦听器端口上进行并发处理。 如果您希望同时处理多条消息，则需要更改此限制。 将其设置为50。

在“侦听器”端口上设置了“ 最大邮件数”值以及“ 最大会话数”并发设置。 如果将“ 最大邮件数”设置为大于默认值1，则可以在同一上下文中多次调用MDB实例的onMessage方法。 当交易时间短时，这可以显着提高吞吐量。 将此值设置为5。

侦听器端口与JMS ConnectionFactory关联，后者本身提供了可调连接池。 每个活动连接都维护一个会话池，该会话池也可以通过ConnectionFactory的属性进行调整。 每个活动的侦听器端口将使用一个连接。 当MessageListener线程代表侦听器端口传递消息时，它将使用该侦听器端口的连接所拥有的会话池中的会话。

有一系列的池和限制，其中每个池的大小必须足以支持上述池。 MessageListener线程池应大于任何侦听器端口的“ 最大会话”值； 多少取决于您希望系统在负载下的行为。

ConnectionFactory的连接池应大于侦听器端口的数量，并具有为使用该ConnectionFactory任何应用程序保留的容量。 会话池应足够大，以覆盖使用该连接的所有侦听器端口的“ 最大会话数”值。 因此也将其设置为50。

客户端与绑定传输

开箱即用，只要您在JMS工厂资源中定义CLIENT传输，就可以将WebSphere Application Server设置为与WebSphere MQ通信。 $ WAS_HOME / lib / WebSphere MQ / java / lib目录中存在mq.jar和mqjms.jar文件，可以确保此支持。

但是，当WebSphere MQ和WebSphere Application Server位于同一z / OS系统中时，可以使用更快的BINDINGS传输，该传输使用共享内存位置而不是WebSphere Application Server和WebSphere MQ之间的TCP / IP调用。

要启用BINDINGS传输：

• 通过在应用程序服务器的库路径中包含libwmqjbind ，使一些WebSphere MQ本机库对WebSphere Application Server libwmqjbind 。 您可以通过在WebSphere管理控制台中将$MQ_HOME/java/lib目录添加到WebSphere环境（ LIBPATH和java_lib_path ）来插入该库。 只需确保在运行WebSphere Network Deployment系统时更改服务器节点的LIBPATH ，而不更改Deployment Manager节点。
• 将正确的数据集添加到CR（ V0SR01C ）和服务器区域（ V0SR01CS ） STEPLIB条目中。 只需检查队列管理器作业日志并标识以下数据集的全名即可： SCSQANLE, SCSQAUTH, SCSQMVR1,和SCSQLOAD 。 为了使数据STEPLIB为CR的STEPLIB路径的一部分，您需要对所有四个数据集都授予授权程序工具（APF）授权。

配置WebSphere MQ

我们假设您已经有一个队列管理器，其中运行了本地队列定义。 该队列应允许PUT和GET并且应具有合理的最大深度。 队列必须设置为SHARE 。

痕迹

为了获得最佳性能，请始终在TRACE(G) OFF 。 这可能节省多达30％的CPU成本。

我们发现，与在队列管理器启动后关闭跟踪的情况相比，在跟踪已关闭的情况下启动队列管理器可能会为您增加5％的CPU。 要禁用的痕迹，集TRACSTR=NO定义中的参数数据集为你的队列管理器xxxxZPRM和TRAXSTR=NO在... .XPRM通道启动。

管理您的讯息

通过将短消息与长消息分开放置在不同的页面集（队列）和不同的缓冲池中，可以将它们与长消息分开。 您应该在页面集中留出足够的空间以容纳预期的峰值邮件容量。

在一个工作单元（即一次提交的范围内）中处理多个相当小的消息，但通常每个工作单元不超过50条消息

Combine many small messages into one larger message, particularly where you will need to transmit such messages over channels. In this case, a message size of 30KB would be sensible.

Nonpersistent messages require no log data. NPMSPEED(FAST) channels require no log data for batches consisting entirely of nonpersistent messages. So use different channels for persistent and nonpersistent messaging. Use up to a max of 4 Buffer Pools of around 50,000 pages. Buffers pools of up to 200,000 pages are not unusual. Make sure your system related messages, long-lived messages and short-lived messages sit on different buffer pools.

Use nonpersistent local queues when possible. Shared queue performance is significantly influenced by the speed of the Coupling Facility (CF) links employed. Shared nonpersistent queues perform better than local private persistent queues.

Specify a codepage in the queue manager definition parameter dataset (eg xxxxZPRM), such as QMCCSID=500 . The same value of codepage has to be set in the definition of the connection factory in WebSphere Application Server (see step 3). We noticed that, if the value is not set, performance degrades of around 10%.

WebSphere MQ connections

Every time WebSphere MQ uses MQCONN , WebSphere MQ loads a program module. If WebSphere MQ does this frequently, then there is a very heavy load on the STEPLIB library concatenation. In this case, it is appropriate to place the SCSQAUTH library in the CSVLLAxx parmlib member LIBRARIES statement and the entire STEPLIB concatenation in the FREEZE statement.

Each conversion type from one code page to another requires the loading of the relevant code page conversion table. This is done only once per MQCONN , however, if you have a many batch programs instances which process only a few messages each then this loading cost and elapsed time can be minimized by including the STEPLIB concatenation in both the LIBRARIES (..) and FREEZE (..) lists.

WebSphere MQ logs

Try to keep as much recovery log as possible in the activelogs on DASD. If you use devices with in-built data redundancy (for example, Redundant Array of Independent Disks (RAID) devices) you might consider using single active logging.

If you use persistent messages, single logging can increase maximum capacity by 6 - 10% and can also improve response times. To achieve single logging set TWOACTV=NO , TWOARCH=NO and TWOBSDS=NO in the queue manager definition parameter dataset.

Keep at least four active log data sets for dual logging; two in case of single logging. Your logs should be large enough so that it takes at least 30 minutes to fill a single log. A size of a 1,000 cylinders per log is reasonable.

There should be no other data set with significant use on the same pack as an active log: ideally, each of the active logs should be allocated on separate, otherwise low-usage DASD volumes. As a minimum, no two adjacent logs should be on the same volume.

WebSphere MQ channels

A channel initiator processing a large number of persistent messages across many channels might need more than the default 8 adapter TCBs for optimum performance. This is particularly so where achieved batch size is small, because end of batch processing also requires log I/O, and where thin client channels are used. We recommend CHIADAPS(40) and CHIDISPS(25) for such very heavy message workloads.

For nonpersistent messages, choosing NPMSPEED(FAST) gains efficiency, throughput and response time but messages can be lost (but never duplicated) in certain error situations. Set BATCHSZ to x and BATCHINT to y where you typically expect x or more messages in y milliseconds and you can afford the up to y milliseconds delay in response time on that channel.

Do not allow TCP/IP connection to be kept alive. Set CHITCPKEEP(NO) . Extra processing is used to keep connections open and it is not appropriate when your application connects and disconnects very frequently.

Debug performance

Browsing the WebSphere Application Server SR log in the job V0SR01CS is always a good way to make sure no exceptions are thrown by the server while connecting to WebSphere MQ. However, this is not the full story.

Before any message is exchanged, the MDB in the SR holds a connection to the WebSphere MQ queue manager. The MDB is ready to consume a message in the WebSphere MQ queue as soon as the WebSphere Application Server CR notifies it that there is one available. But the CR has not yet contacted WebSphere MQ. The CR will only contact WebSphere MQ after the first message arrived in the queue. Therefore, connection problems between WebSphere Application Server and WebSphere MQ will only arise after the test has started. Look for exceptions in the CR V0SR01C job log.

结论

In this article, we explained how to tune your existing z/OS system to achieve best performance when running a JMS application over WebSphere Application Server. We described the tuning steps for both the embedded messaging engine and WebSphere MQ. We showed several important parameters for the configuration of destinations and connection factories. We highlighted crucial values for several thread-pools in the EJB container and in the resource adapter for Platform Messaging. We explained the particular architecture of WebSphere Application Server for z/OS and the tuning applicable to it. We listed performance settings for WebSphere MQ's channels, WebSphere MQ managers, logs and WebSphere MQ connections.

This article described the general tuning steps necessary for an efficient and scalable starting system. To go beyond that, experience and good-design in developing J2EE applications cannot be substituted.

---

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/0608_oriato/0608_oriato.html