Performance tuning

We can tune the relative performance of each MQIPT route by using a combination of a thread pool and an idle timeout specification.

Connection threads

Each MQIPT route is assigned a working pool of concurrently running threads that handle incoming communication requests. At initialization, a pool of threads is created (of the size specified in the route's MinConnectionThreads attribute), and a thread is assigned to handle the first incoming request. When this request arrives, another thread is assigned, ready for the next incoming request. When all threads are assigned for work, a new thread is created, added to the working pool, and assigned for work.

In this way, the pool grows until the maximum number of threads (specified in MaxConnectionThreads) is reached. Threads are released back to the pool when a conversation ends, or the specified idle timeout period has elapsed. When the maximum number of working threads is reached, the next incoming request waits until a thread is released back to the working pool.

We can reduce the time that requests might have to wait by increasing the number of available threads. However, we must balance this increase with the system resources that are available.

Idle timeout

By default, working threads are not terminated because of inactivity. When a thread has been assigned to a conversation, it remains assigned to that conversation until it is closed normally, the route is deactivated, or MQIPT is shut down. Optionally, you can specify an idle timeout interval (in minutes) in the IdleTimeout property so that threads that have been inactive for the specified period of time are recycled. Threads are recycled for use by placing them back into the working pool.

If IBM MQ activity is intermittent, set its heartbeat interval to a value less than that of the MQIPT timeout so that threads are not constantly recycled.

Parent topic: Administer IBM MQ Internet Pass-Thru