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
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 the 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 the 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 the 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, the 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 the 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 the 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 you have a single message to put on a queue. 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 we are filling up the space associated with the IBM MQ for IBM i queue managers.
- Is the application or IBM MQ for IBM i running slowly?
- If the 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 the 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 we 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 the 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?
Parent topic: Design considerations for IBM MQ applications