Introduction

IBM® WebSphere® Message Broker (hereafter called Message Broker) can serve as an enterprise service bus (ESB) that provides universal connectivity for various protocols as well as data conversion and data transformation for applications using both structured and unstructured data formats.

Message processing performance depends on various factors, including hardware capability, software configuration, message flow and message format design and implementation, and the number of message flow instances. This article describes best practices for implementation and deployment that yielded improved performance and availability of message flow services in various customer locations. While the article does not cover best practices for associated WebSphere MQ and database implementations, it does touch on them from the message broker application perspective. Best practices are not one size fits all, and in some cases, the best practices described here need to be modified for architectural flexibility and for individual customer requirements and capabilities.

Best practice areas

Message flow

Best practices during the message flow development stage, including how to avoid message flow implementations that can cause performance problems.

ESQL

Best practices during ESQL development in the message flows, including developing reusable code and minimizing optimized ESQL code in the message flows, purely from a performance improvement perspective.

Pub/Sub

Best practices for those who use the pub/sub model for routing messages. Collective and cloning best practices are not covered.

WebSphere MQ best practices from a Message Broker perspective

This section doesn't describe all relevant WebSphere MQ best practices, but does show you how to tune WebSphere MQ for performance when Message Broker acts as a MQ client application.

Database best practices from a Message Broker perspective

This section doesn't describe all relevant database best practices, but does show you how to tune WebSphere MQ for performance when Message Broker acts as a database client application.

Configuration

Best practices during the Message Broker setup, configuration, and deployment phases. Best practices specific to high availability environments are not covered.

Message flow

• Often, to separate configuration information from business logic, customers externalize configuration information to a file or database. This technique can reduce performance, because reading a configuration or parameters file is a one-time activity at the time of the first instance of a node is created or at the time the first message is processed, instead of a loop checkup for each message. Since Message Broker is more CPU-oriented than I/O-oriented, it is usually best to avoiding I/O operations involving files or databases when possible.
• Use the partial parsing methodology whenever possible, unless business needs require a complete parsing of the message, At the end of the message flow, if there is an output node, such as MQOutput, then message serialization (conversion to bitstream) occurs and the complete message is parsed. This Message Broker feature helps improve performance, so take advantage of it whenever possible.
• Processing cost is directly proportional to the size of the message tree. Hence message tree size and design plays a crucial role in the processing cost. For example, place all those fields which might be used in decision making to route the messages at the beginning of the message. Due to partial parsing the message tree will not be parsed completely and the message will be routed to next node. If the message contains user maintainable data folders in the headers like MQRFH2 usr folder then its best recommended to store the decision making routing elements in it.
• Wherever possible reduce the number of nodes in the message flows. Also try to reduce the message tree copies or creating new message trees. Message tress occupy good amount of space especially if there are lot of elements. Use nodes like compute (which provide the capability to modify the tree) only when necessary, to avoid message tree copies. This not only brings efficiency with respect to memory utilization but also increases the processing speed.
• Avoid using Reset Content Descriptor nodes. An RCD node is intended to change the message domain which actually parses the complete message tree. This is both memory and CPU intensive activity.
• A logical combination of IF statements, "CREATE with PARSE" statement and ESQL ASBITSTREAM can be used to eliminate RCD nodes and multiple compute/filter nodes.
• Do not use trace nodes on production environments. Using ${Root} expression is expensive operation as this causes the complete message tree parsing. This happens even if the destination is not an active one.
• Wherever possible use user-exits and redirect the audit / logging information appropriately. User exit feature gives the flexibility to activate & deactivate them dynamically during message processing.
• Save intermediate results in the message tree in order to avoid recalculating them in subsequent nodes. If the message contains user maintainable data folders in the headers like MQRFH2 usr folder then store the intermediate results in it for subsequent nodes.
• Using destination list is more recommended rather than using more nodes when message has to be written to multiple destinations.
• When using XMLT nodes, be aware that the message tree is first serialized and then sent to transformation engine. After the style sheet is loaded and transformation is performed, the node re-parses the result into a message tree. Also till Message Broker V6 the output of the XMLT node is always BLOB format and hence an RCD node is a must if the message processing has to continue further as an XML message in the message flow. So by using XMLT node multiple times the entire message tree is parsed. This is very expensive if the message trees to be transformed are large. In the same place if ESQL is used with a better logic, then the processing cost would be drastically different with more benefits as complete message tree parsing is not needed.
• If XMLT nodes are to be used then make use of style sheet caching wherever possible.
• Use message flows only for performing mediation activities like transformation, translation, protocol conversion, message enrichment, and routing. Message flows should be stateless engines in the mediation activities.
• Ensure transaction mode is set to 'NO' for input nodes and 'Automatic' for output nodes during message processing. These should differ only when processing has to be done under transaction mode.
• Always have exceptional handling mechanism for the message flows rather than relying on the default broker exception handler. The default exceptional handler can block the message consumption when a single poisoned message processing is failed.
• Use subflows for code reuse across multiple message flows, especially if you are using or considering multiple protocols.
• In a filter node or Database node it is not possible to modify the message tree, in such cases use Environment tree in the nodes to modify the message tree contents and copy it in the subsequent nodes.
• If there are database manipulating nodes then promote the data source name property as it might not be same across various environments (development, test, production, etc). Promoting the property helps to change it, at a flow level rather than at each node level during deployments on various environments. The same applies to other node properties like style sheet name for XMLT node.
• Revisit all the java nodes and ensure that there is a clearMessage() called on every MbMessage object especially in the finally block. MbMessage object is used to create output message tree, environment tree, local environment tree, exception list tree, etc. So where ever the message trees are created, clear them out in the try - finally block.
• It is strongly recommended to have fewer, more complex nodes rather than having large number of nodes with the processing logic spread across.
• Each message flow is a thread. For effective processing integrity it is not good to spawn additional threads in the message flow nodes. If a business requirement arises then all the threads should be maintained by the node itself and release them at the time of node deletion ensuring that there is no thread blocking during message processing.

ESQL

• Wherever possible avoid using Local Environment tree and use Environment tree for scratchpad work. Only one copy of the Environment tree exists for all the nodes of the message flow instance but for Local Environment, the message tree is copied for every node it is propagated.
• Use dynamic references during ESQL coding in order to improve the efficiency of message tree navigation.
• Use parameter markers '?' when using the PASSTHRU statement in ESQL. This is so that the Dynamic SQL statement can be reused.
• Do not have same function call for the same purpose in the loops. For ex: Calling CARDINALITY function in an ESQL WHILE loop is expensive.
• If there is a need to send multiple output messages of the same input message then Use PROPAGATE function in the ESQL. This helps to reclaim the storage of the output message tree, for every message propagation that is done. This way memory utilization of the message flow can be reduced. Also avoid looping of the flow using hard wiring.
• Use ROW and LIST constructors to create lists of fields. Also it is good to do variable initialization at the time of declaration itself. Thus wherever possible reduce the number of ESQL statements. This increases performance and reduces the amount of internal memory objects that were created and parsed.
• ESQL String manipulations are processor intensive operations. Try to minimize their usage as much as possible.

Publish/subscribe

• When using pub/sub, the number of subscribers per topic will affect message throughput as this will determine how many output messages have to be written per publication on a topic. The messages will be written in a single unit of work so the broker queue manager log needs to be tuned when using persistent messages.
• Use of publication nodes can lead to increased use of the broker database especially if they are retained publications as broker stores them in the broker database. So be judicious if the publications have to be retained publications or not.
• Details of each subscription registration and de-registration is stored in the broker database table. If the level of dynamic subscribing or unsubscribing by applications is too high, then there will be greater level of broker database operations. All I/O and DB operations are expensive. So design a solution in such a way that these operations are minimized or tune the database for high performance.
• When designing publish / subscribe model consider content based routing over topic based routing. By using content based routing, it is easy to evaluate an SQL expression against the contents of a message and take a decision whether the subscriber really need to get the message or not. This helps in the reduction of number of messages sent from the broker to the subscribers. On topic based routing, the subscriber would get all the messages on the registered topic. The subscriber might not need all the messages and might discard them based on the content. Thus content based routing helps the subscribers get the most of those messages that they really need.

WebSphere MQ best practices from a message broker perspective

• Message broker processing performance is better when the flow is designed to be CPU bound (only if it is not starved of CPUs). When it comes to persistent messages over WebSphere MQ it becomes I/O bound as WebSphere MQ logs it. So do not make the messages persistent if the business need does not exist. Also set expiry for every non-persistent message. Once the buffer is size is full, even for the non persistent messages WebSphere MQ makes I/O operations so set expiry to the messages to avoid queue pile up when broker or application does not do processing or message consumption.
• When using persistent messages over WebSphere MQ, increase the buffer sizes and log extent size of the queue manager log. Also, consider using low latency disks on which the log is located such as one with a nonvolatile write cache. This can significantly improve the rate at which persistent messages can be processed.
• If WebSphere MQ I/O is unavoidable, then try to reduce it wherever possible. For example:
• Keep the message processing rate at a high volume so that the number of messages on queue are minimal irrespective of the type of the messages. You can achieve it with multiple execution groups and multiple instances of the message flows.
• Avoid large differences in message arrival and processing rates. Tune the message flows and configuration as suggested above.
• Use large buffers with fast disks for queue manager logging.
• Run Message Broker as a trusted application on all the supported platforms. This helps in the reduction of application (broker) communication cost with the queue manager.

Database best practices from a message broker perspective

• I/O operations and database operations are expensive. Wherever possible minimize the number of such operations in the solution. Try to build cache wherever possible. The decision is purely business scenario driven. Excessive cache build is also not recommended.
• When the solution has database operations to perform, then several best practices related to db applications need to be followed. The next few recommendations are from a Message Broker application perspective with DB2 as the database, but they also apply to most other databases.
• Tune application heap size (APPLHEAPSZ) and the application control heap size (APP_CTL_HEAP_SZ). It is not possible to recommend a fixed value as it depends on the business condition and solution implementation. In order to determine a value issue the largest message transaction to the database (as per business requirement) and monitor the heap size.
• Tune the bufferpool size if the application has the ability to work with large objects such as BLOBs, CLOBs and VarCahrs (as these are accessed using the memory area of the database).
• Ensure that locklist and maxlocks are large enough, or else reduce the unit of work by issuing commit statements more often.
• Use indexes wherever possible to reduce the contention between message flow instances and applications.
• Where a message flow only reads data from a table, consider using a read only view of that table. This reduces the amount of locking within the database manager and reduces the processing cost of the read.
• If database operations are unavoidable then at least reduce them by:
• Making the database local to the system where message broker resides
• Having high buffer sizes
• Using fast disks for data and logs.
• When using the SELECT statement, make the WHERE clauses efficient to minimize the amount of data retrieved from a database.
• When possible, use stored procedures as they are already compiled and stored in the database. This increase the speed of data retrieval.
• When possible, avoid complex joins as they are expensive due to the processing time consumption.

Configuration

• If there are multiple message broker components (not on the same machine), use separate user-ids per component in large deployments. This is for security and easy maintenance.
• Do not have direct login access to the component service ids. Provide privileges to a user id which can sudo to the service id to perform the operations. This helps in securing the components.
• Do not disclose component service id to the users. Users can launch the toolkit with service id using "runas" command and can have complete privileges on the component, as the service id will be granted with full topology level privileges in the ACL by default.
• Use Access Control Lists to define component level operation privileges.
• Once the complete setup is done, reduce the dependency on toolkit use for administrative operations. Use alternate solutions like configuration proxy manager API exerciser or use the commands on the local machine. Ensure that administrative activities can not be performed from remote machines, for security reasons. For this, you can set the MCA channel user id of the SYSTEM.BKR.CONFIG channel of configuration manager queue manager value to an invalid user id value. This ensures that any further administrative operations from the toolkit can not be performed.
• Do not set environment configuration related information in "mqsiprofile", rather set it inside a user profile. During maintenance activities (like Fix Pack updating), these files will be over written and the previous settings would be lost.
• Set ulimit to an appropriate value as per the company policies based on the expected load and available system resources This applies to non-windows machines.
• Based on performance tests, arrive at a process size. Increase the execution group (DataFlowEngine) data segment size (only AIX) as needed. The default value of 1 GB might not be sufficient if you are using 32 bit execution groups for complex and large number of message flows in the environment.
• Use 64-bit processes (execution groups) rather than 32 bit processes from memory perspective.
• If there is significant usage of java inside the message broker solution, then conduct several performance tests to determine JVM maximum heap size. It should be noted that the JVM heap size is allocated from the DataFlowEngine (Execution Group) process. So never set the values of process heap size and JVM maximum heap size to be same.
• Perform all deployment activities using scripts or appropriate message broker commands. Set the environment variable MQSI_SHOW_DEPLOY=1 to see the detailed deployment operation progress in the operating system user log. Querying operations like mqsilist <brokername> is also a deploy message so you would notice deployment information in the userlog.
• Always maintain an environment inline to the production environment with same level of configuration. If any maintenance has to be performed first perform it on the clone and ensure that it does not impact your solution. Later perform it on the production.
• Strictly define naming conventions and coding standards. Ensure all developers and administrators follow it accordingly.
• Have source control mechanism for all message broker artifacts and use deployment scripts (ant or shell scripts) for easy maintenance.
• Do not share the same queue manager across components (broker, username server, configuration manager) especially on production environment.
• Use the additional instances mechanism to increase the number of copies of a message flow that are running in an execution group, instead of allocating one copy of the message flow to each of many execution groups.
• Always maintain a document to track all the changes made on production environment. Even a minute change at times can bring catastrophic results. If the activities are logged, it is easy to debug and restore the environment quickly.
• Always perform a domain level backup and restoration. During a domain level backup there shouldn't be any outstanding deploys in place and shouldn't perform any deploys till the backup is complete.
• Always take a backup before performing any changes to the domain or system environment (regular maintenance like fix pack upgrades) which helps in easy restoration if a failure is noticed after the upgrade.
• Keep a policy in place to test and maintain backup and recovery strategy especially keeping disaster recovery scenario in view.

Conclusion

This article described some WebSphere Message Broker best practices. While use of these best practices should improve message processing performance, the performance also depends on other factors such as effective tuning of any dependant WebSphere MQ and database instances, good solution design, and machines with high-performance CPUs and sufficient memory.

Acknowledgements

Special thanks to Amar A Shah (WebSphere Message Broker Level 3 Technical Lead), Raja Sreenivasan (WebSphere Message Broker Administrator in Bharti), and Raghavendran Sreenivasan (WebSphere Message Broker Level 3 Team Lead) for reviewing this article and providing their valuable feedback.

Resources

• IBM Redbook: Patterns: Broker Interactions for Intra- and Inter-enterprise
  Patterns for e-business are a group of proven, reusable assets that help increase the speed of developing and deploying Web applications. This IBM Redbook concentrates on distributed application integration using the Application Integration::Broker and Extended Enterprise::Exposed Broker application patterns for inter-enterprise.
  
  
• Improve the performance of your WebSphere Message Broker message flow
  Ever wondered why your message flow is not running as fast as you'd like? This article describes what is happening inside your message flow as it processes messages, and help you identify hotspots and expensive pieces of code.
  
  
• WebSphere Business Integration Message Broker performance information
  A quick-reference to various sources of performance information.
  
  
• Tuning a WebSphere MQ Integrator Broker
  Recommendations for configuring and tuning a WebSphere MQ Integrator broker and related components in order to maximize the speed of message processing.
  
  
• Determining how many copies of a message flow should run in WebSphere Message Broker
  This article explains how a message flow runs in an execution group and helps you understand the processing characteristics of your own message flows, so that you run sufficient copies.
  
  
• WebSphere Message Broker developer resources page
  Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
  
  
• WebSphere Message Broker product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere Message Broker information center
  A single Web portal to all WebSphere Message Broker V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
  
  
• WebSphere Message Broker documentation library
  WebSphere Message Broker specifications and manuals.
  
  
• WebSphere Message Broker forum
  Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
  
  
• WebSphere Message Broker support page
  A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
  
  
• Redbook: Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
  Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying e-business applications. This Redbook shows you how to use WebSphere ESB together with WebSphere Message Broker to implement an ESB within an SOA. Includes scenario to demonstrate design, development, and deployment.
  
  
• developerWorks WebSphere Business Integration zone
  For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  
  
• WebSphere Business Integration products page
  For both business and technical users, a handy overview of all WebSphere Business Integration products
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Technical books from IBM Press
  Convenient online ordering through Barnes & Noble.
  
  
• developerWorks technical events and Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Best practice areas
• Message flow
• ESQL
• Publish/subscribe
• WebSphere MQ best practices from a message broker perspective
• Database best practices from a message broker perspective
• Configuration
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Webcast: WebSphere Message Broker: Converting Maps to ESQL using Support Pac IA9Y
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere Message Broker

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers