Previous page

Next page

Locate page in Contents

Print this page

Dynamic Limits

In an attempt to provide scalability depending on the system load, pool limits are dynamically changed. Their increase and decrease depend on the completion of processing a request. If the request is killed by the timeout, the system is considered to be too loaded for this many operations of the kind to be performed in parallel, and so the dynamic pool limit is decreased by 1 down to the minimum of 1. If the operation was successful, the dynamic pool limit is increased by the 1/comeback_ratio value up to the corresponding static limit. It allows a faster reaction to heavy load peaks and slower recover. Dynamic limits exist for each of the static limits: normal, heavy, and urgent. Decreasing a dynamic limit happens not only for the limits of the given message class (judging by the message whose processing was terminated for the timeout), but also for heavier classes of messages. It means that the timeout of an urgent message will lead to all of the three dynamic limits being decremented. Incrementing a dynamic limit would also affects all the limits of lighter classes. Thus, the completion of a heavy message allows to increment the dynamic limits for all of the message classes. The incremental values are proportional to the corresponding static pool limits. Here is an example.

Suppose we have the following pools: 4 for heavy, 10 for normal and 20 for urgent messages and the comeback_ratio equalling 4. A successful completion of an urgent messages will result in the following increases.

Urgent Dynamic Limit = +1/comeback_ratio.

Normal Dynamic Limit = +1/comeback_ratio/(20/10).

Heavy Dynamic Limit = +1/comeback_ratio/(20/4)

This allows heavier limits not to stick near their minimums if messages of their class are not coming.

Please send us your feedback on this help page