Intel AS/400 RISC Server, 170 Servers, 7xx Servers 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. http://www-1.ibm.com/servers/eserver/iseries/btob/connect/pdf/whtpaperv11.pdf

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.

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.

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).

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.

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.

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.

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:

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. http://www-4.ibm.com/software/ts/mqseries/messaging/

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
© Copyright IBM Corp. 2008	Chapter 6 - Web Server and WebSphere	124