The large assortment of configuration parameters permits a high degree of control over processing speed, memory use, and disk space. The JMS IQ Manager properties work together to enable you to fine-tune your system according to load and hardware constraints. For information, refer to Segment Properties.
Because every message is written to disk, file input/output (I/O) is usually the hardware factor with the largest performance impact. For a disk with adequate I/O speed, highest performance is achieved by holding all messages in server memory continuously until the corresponding segment is cleaned up.
Available server memory can easily be exceeded for systems handling very large messages, so several configuration parameters are provided to help you manage a memory-bound server. See Throttling Producers for additional information.
To maximize performance:
Use the fastest disk possible.
Keep in mind that allocating a new segment requires more time than freeing a cleaned-up segment.
Set the segment size to lower values, because smaller segments turn over more rapidly and thus provide more effective use of server memory. However, because cleaning up two small segments requires more time than cleaning up one large segment, you can use very large segments to increase performance on systems that are constrained by disk I/O speed rather than memory or space.
In addition to disk and memory-management features provided by the operating system, special configuration properties within the JMS IQ Manager specifically deal with messages, message destinations, and producers.
When the amount of JMS IQ Manager memory allocated to messages reaches a certain limit, you can instruct the JMS IQ Manager to stop reading all messages from one or more producers until certain criteria are met. This process is referred to as throttling the producer.
Producer throttling is done on a per-message destination basis. This process addresses the two most common reasons for approaching the JMS IQ Manager memory limit in an otherwise well-tuned system:
A particular message destination has a period of abnormally heavy traffic.
Throttling all producers that feed the message destination gives the destination’s consumer a chance to catch up while maintaining normal throughput for other message destinations.
A particular consumer fails, causing a backup of all message destinations to which it subscribes.
If the problem is transient, then throttling all its producers gives the consumer a chance to catch up on the backlog. If the problem is permanent, then throttling the producers allows unaffected message destinations to flow freely. Meanwhile, the problem can be diagnosed and repaired without taking the server offline.
Three configuration properties govern producer throttling:
The Server Throttling Threshold property sets the message server limit. When the JMS IQ Manager is below this threshold, it does not throttle any producers, whether or not they are feeding a destination that has exceeded the Per-Destination Throttling Threshold.
When the Server Throttling Threshold has been exceeded and producer throttling is in effect, the Per-Destination Throttling Threshold property specifies the per-destination limit. The JMS IQ Manager stops reading messages from producers feeding any message destination that has exceeded this limit.
Throttling lag determines how many messages for this topic must be removed from the queue before throttling can stop.
Once throttling has been initiated, the JMS IQ Manager resumes reading messages for the affected message destinations only when one of the following criteria is met:
The JMS IQ Manager falls below the Server Throttling Threshold limit.
The number of undelivered messages in the affected destination has dropped to less than the difference between the value specified by the Per-Destination Throttling Threshold and the value specified by the Throttling Lag.
Each message in a message destination counts against the message destination’s Per-Destination Throttling Threshold limit until the message is dequeued. In particular, a non-transactional message is counted until it has been delivered to all its subscribers, whereas a transactional or XA-compliant message is counted until it has been committed by all consumers.
The following table illustrates a scenario where a JMS IQ Manager exceeds its specified threshold and begins to throttle selected producers. In this example, the JMS IQ Manager uses the following (default) values for throttling properties:
Server Throttling Threshold = 100,000
Per-Destination Throttling Threshold = 1,000
Throttling lag = 100
Two minutes after the server exceeds its limit, Topic_A, which has two subscribers and one publisher, is affected. Its publisher is throttled until the number of undelivered messages can drop below 900. Later, because the JMS IQ Manager is no longer loaded, the same topic builds up an even greater backlog without having its publisher throttled.
Table 1–6 Publisher Throttling Example
Time |
Total Messages on All Topics (Server) |
The Highest Sequence Number (Messages in Topic_A only) |
Comment |
||
---|---|---|---|---|---|
Read from Pub1: |
Sent to Sub1: |
Sent to Sub2: |
|||
11:37 |
98604 |
500 |
200 |
75 |
Server is not yet over limit. |
11:38 |
100307 |
800 |
500 |
150 |
Server is now over limit, but Topic_A is unaffected because its subscribers are keeping up well enough. |
11:39 |
101283 |
1100 |
800 |
225 |
Server is still over limit, Topic_A is still unaffected because only 875 messages are undelivered. |
11:40 |
103429 |
1350 |
1050 |
300 |
Now that it has 1050 undelivered messages, Topic_A has crossed the per-destination limit. While the server remains over limit, Pub1 will remain throttled until the number of undelivered messages falls below 900, which is the difference between the value specified by the Per-Destination Throttling Threshold and the value specified by the Throttling Lag). |
11:41 |
104031 |
1350 |
1300 |
375 |
Pub1 is throttled, Sub1 is nearly caught up, Sub2 is catching up but still has 975 undelivered messages. |
11:42 |
103204 |
1350 |
1350 |
449 |
Pub1 is throttled, Sub1 has caught up, Sub2 has 901 undelivered messages, which is still too many. |
11:43 |
102762 |
1350 |
1350 |
451 |
Although the server is still over limit, it unthrottles Pub1 because the undelivered message count for Topic_A has fallen below 900. |
11:44 |
101095 |
1375 |
1370 |
525 |
Server is over limit, but Topic_A is unaffected because it has only 850 undelivered messages. |
11:45 |
100028 |
1575 |
1500 |
600 |
Server is over limit, but Topic_A is unaffected because it has only 975 undelivered messages. |
11:46 |
99248 |
1900 |
1700 |
675 |
Server is no longer over limit. No publishers are throttled even though Sub2 has more than 1000 undelivered messages. |