Design and performance considerations for IBM i applications

Use this information to understand how application design, threads, and storage, can affect performance.

This information is split into two sections:

• Application design considerations
• Specific performance problems

Application design considerations

There are a number of ways in which poor program design can affect performance. These problems can be difficult to detect because the program can appear to perform well, while affecting the performance of other tasks. Several problems specific to programs making IBM MQ for IBM i calls are explained in the following sections.

For more information about application design, see Design considerations for IBM MQ applications.

Effect of message length

Although IBM MQ for IBM i allows messages to hold up to 100 MB of data, the amount of data in a message affects the performance of the application that processes the message. To achieve the best performance from our application, send only the essential data in a message; for example, in a request to debit a bank account, the only information that might need to be passed from the client to the server application is the account number and the amount of the debit.

Effect of message persistence

Persistent messages are journaled. Journaling messages reduces the performance of our application, so use persistent messages for essential data only. If the data in a message can be discarded if the queue manager stops or fails, use a nonpersistent message.

Searching for a particular message

The MQGET call usually retrieves the first message from a queue. If we use the message and correlation identifiers (MsgId and CorrelId) in the message descriptor to specify a particular message, the queue manager must search the queue until it finds that message. The use of the MQGET call in this way affects the performance of our application.

Queues that contain messages of different lengths

If the messages on a queue are of different lengths, to determine the size of a message, our application can use the MQGET call with the BufferLength field set to zero so that, even though the call fails, it returns the size of the message data. The application can then repeat the call, specifying the identifier of the message it measured in its first call and a buffer of the correct size. However, if there are other applications serving the same queue, you might find that the performance of our application is reduced because its second MQGET call spends time searching for a message that another application has retrieved in the time between your two calls.

If our application cannot use messages of a fixed length, another solution to this problem is to use the MQINQ call to find the maximum size of messages that the queue can accept, then use this value in your MQGET call. The maximum size of messages for a queue is stored in the MaxMsgLen attribute of the queue. This method might use large amounts of storage, however, because the value of this queue attribute can be the maximum allowed by IBM MQ for IBM i, which might be greater than 2 GB.

Frequency of sync points

Programs that issue numerous MQPUT calls within sync point, without committing them, can cause performance problems. Affected queues can fill up with messages that are currently unusable, while other tasks might be waiting to get these messages. This problem has implications in terms of storage, and in terms of threads tied up with tasks that are attempting to get messages.

Use of the MQPUT1 call

Use the MQPUT1 call only if we have a single message to put on a queue. If you want to put more than one message, use the MQOPEN call, followed by a series of MQPUT calls and a single MQCLOSE call.

Number of threads in use

An application might require many threads. Each queue manager process is allocated a maximum allowable number of threads. If some applications are troublesome, it might be due to their design using too many threads. Consider whether the application takes into account this possibility and that it takes actions either to stop or to report this type of occurrence. The maximum number of threads that IBM i allows is 4,095. However, the default is 64. IBM MQ makes available up to 63 threads to its processes.

Specific performance problems

This section explains the problems of storage and poor performance.

Storage problems

If you receive the system message CPF0907. Serious storage condition may exist it is possible that you are filling up the space associated with the IBM MQ for IBM i queue managers.

Is our application or IBM MQ for IBM i running slowly?

If our application is running slowly, it might indicate that it is in a loop, or waiting for a resource that is not available. This slow running might also be caused by a performance problem. Perhaps it is because your system is operating near the limits of its capacity. This type of problem is probably worst at peak system load times, typically at mid-morning and mid-afternoon. (If your network extends across more than one time zone, peak system load might seem to you to occur at some other time.)

If you find that performance degradation is not dependent on system loading, but happens sometimes when the system is lightly loaded, a poorly designed application program is probably to blame. This problem might manifest itself as a problem that only occurs when certain queues are accessed.

QTOTJOB and QADLTOTJ are system values worth investigating.

The following symptoms might indicate that IBM MQ for IBM i is running slowly:

• If your system is slow to respond to MQSC commands.
• If repeated displays of the queue depth indicate that the queue is being processed slowly for an application with which you would expect a large amount of queue activity.
• Is IBM MQ trace running?