Intel 7xx Servers User Manual
1.
Connector relative capacity: The different back-end connector types are meant to allow users a
simple way to connect the Connect for iSeries product to their back-end application. Your choice in a
connector type may be dictated by several factors. Clearly, one of these factors relate to your existing
back-end application and the programming language it is written in. This, in itself, may limit your
choice for a back-end connector type. Please see the Connect for iSeries white paper to assist you in
understanding the different connector types.
simple way to connect the Connect for iSeries product to their back-end application. Your choice in a
connector type may be dictated by several factors. Clearly, one of these factors relate to your existing
back-end application and the programming language it is written in. This, in itself, may limit your
choice for a back-end connector type. Please see the Connect for iSeries white paper to assist you in
understanding the different connector types.
Performance was measured for a simple cXML New Order Request. The Java connector performance
may vary depending on the code you write for it. All connectors “mapped” approximately the same
number of “fields” to make a fair comparison. The PCML connector has overhead associated with it
in starting a job for each transaction via “SBMJOB”. You can pre-start a pool of these jobs which
may increase performance for this connector type.
may vary depending on the code you write for it. All connectors “mapped” approximately the same
number of “fields” to make a fair comparison. The PCML connector has overhead associated with it
in starting a job for each transaction via “SBMJOB”. You can pre-start a pool of these jobs which
may increase performance for this connector type.
2.
XML Validation: XML validation should be avoided when not needed. Although many businesses
will decide to have this feature on (you may not be able to assume the request is both “well formed
and validated”) there are significant performance implications with this property “on”. One thought
would be to enable XML validation during your testing phase. Once your confident that your trading
partner is sending valid and well-formed XML, you may want to disable XML validation to improve
performance.
will decide to have this feature on (you may not be able to assume the request is both “well formed
and validated”) there are significant performance implications with this property “on”. One thought
would be to enable XML validation during your testing phase. Once your confident that your trading
partner is sending valid and well-formed XML, you may want to disable XML validation to improve
performance.
3.
Tracing: Try to avoid tracing when possible. If enabled, it will impact your performance. However,
in some cases it is unavoidable (e.g. trouble shooting problems).
in some cases it is unavoidable (e.g. trouble shooting problems).
4.
Management Central Logging: This feature will log transaction data to be queried and viewed with
Management Central. Performance is impacted with this feature “on” and must be taken into
consideration when deciding to use this feature.
Management Central. Performance is impacted with this feature “on” and must be taken into
consideration when deciding to use this feature.
5.
MQ Series Management Central Audit Queue: Due to the fact that the Management Central
Auditing logs messages into a MQ Series queue for processing, the default queue size may not be
large enough if you run at a very high transaction rate. This can be adjusted by issuing wrkmqm and
selecting the queue manager for your Connect for iSeries instance, selecting option 18 (work with
queues) on that queue manager, selecting option 2 (change) and increasing the Maximum Queue
Depth property. This property, when enabled, added approximately 15% overhead to the “B2B New
Order Request” workload.
Auditing logs messages into a MQ Series queue for processing, the default queue size may not be
large enough if you run at a very high transaction rate. This can be adjusted by issuing wrkmqm and
selecting the queue manager for your Connect for iSeries instance, selecting option 18 (work with
queues) on that queue manager, selecting option 2 (change) and increasing the Maximum Queue
Depth property. This property, when enabled, added approximately 15% overhead to the “B2B New
Order Request” workload.
6.
Recovery (Check pointing): Enabling transaction recovery adds significant overhead. This should
be avoided when not needed. This property when enabled added approximately 50% overhead to the
“B2B New Order Request” workload.
be avoided when not needed. This property when enabled added approximately 50% overhead to the
“B2B New Order Request” workload.
7.
MQ Series Connector Queue Configuration: By default, in MQ Series 5.2, the queue manager
uses a single threaded listener which submits a job to handle each incoming connection request. This
has performance implications also. The queue manager can be changed to having a multithreaded
listener by adding the following property to the file
\QIBM\UserData\mqm\qmgrs\QMANAGERNAME\qm.ini
Channels:
uses a single threaded listener which submits a job to handle each incoming connection request. This
has performance implications also. The queue manager can be changed to having a multithreaded
listener by adding the following property to the file
\QIBM\UserData\mqm\qmgrs\QMANAGERNAME\qm.ini
Channels:
ThreadedListener=Yes
The multithreaded listener can boast a higher throughput, but the single threaded listener is able to
handle many more concurrent connections. Please see MQ Series site for help with MQ Series.
handle many more concurrent connections. Please see MQ Series site for help with MQ Series.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 6 - Web Server and WebSphere
124