OpenESB tuning:
I'm still working on this
GlassFish tuning guide:
http://wiki.glassfish.java.net/Wiki.jsp?page=PerformanceTuningGuide
JVM tuning guide:
http://java.sun.com/performance/reference/whitepapers/6_performance.html
The Connectivity Map for this use case with
MQSeries eWay
would look like this:
The concurrency for outbound MQ operations (in this case, put
to MQ_RESPONSE) is configurable
using the Outbound MQSeries eWay connection pool settings. The default
is a maximum
of 20 concurrent connections to MQ for the puts.
However, the inbound MQ operation (receive) uses
only 1
channel per CM link and a pool size cannot be configured for the number
of
concurrent listeners (this is due to a limitation in the underlying IBM
API
where XA will not work when channels are pooled)
To overcome this serial behavior on the inbound
side, use
multiple MQ eWay links on the connectivity map configured for the same
inbound
queue (in our example, MQ_REQUEST). In the example below, 3 inbound MQ
eWay
links are made to the same business process to force 3 concurrent
channels
(listeners) to the same queue and hence increasing the concurrency 3
folds.
All 3 links are configured to talk to the same IBM queue and
the polling interval was reduced from the default of 5 seconds to every
100ms.
There are other ways to use the MQSeries eWay for high
throughput. For instance, the process could be triggered by a Scheduler
and use MQSeries eWay in outbound mode to do a BulkGet operation that
gets every
message on the queue. However, this requires modifying business logic
to enable
concurrent processing.
A cleaner approach for configurable concurrency is to use the JMS interface to MQ as seen below.
This option uses the default JMS design time artifacts of JavaCAPS and points to IBM WebSphere MQ as the JMS provider. The example below shows the same BP seen earlier, this time redesigned to use corresponding JMS operations instead of the MQ eWay operations.
On the connectivity map, use the JMS Queue or Topic artifacts from the palette. In the case of JMS, the name given on the connectivity map is very important since it signifies the actual name of the IBM MQ queue/topic (In this case, queues named ‘MQ_REQUEST’ and ‘MQ_RESPONSE’)
The inbound and outbound concurrency is configured using the standard JMS configuration in JavaCAPS. That is, outbound concurrency via the ‘maximum pool size’ parameter on the outbound link and inbound concurrency via the ‘connection consumer mode’ on the inbound link. When using connection consumer mode for concurrency, the server session pool size allows you to create multiple listeners (default of 5) to the same endpoint.
On the Environment, under your logical host, create a new ‘IBM WebSphere MQ’ server to represent your MQ Server as a JMS provider.
Configure the Webphere MQ JMS provider as shown below (details on available configuration options covered below)
When building and deploying to this Environment, make sure that your MQ JMS endpoints (MQ_REQUEST, MQ_RESPONSE) get mapped to the 'WebSphereMQ' server and not to another JMS server (like the default Sun Seebeyond JMS IQ Manager).
These jar files need to be obtained from your IBM WebSphere install location and are not shipped by Sun. After the jar file locations are added to the classpath, a restart will be required so the jars are loaded by the app server.
/logicalhost/extras/JMSJCA-readme.html
/logicalhost/extras/rawmq-readme.html