Adaptive Middleware for Message Queuing Systems
Distributed database systems are usually built on top of middleware solutions, such as message queuing systems. Adaptive message queuing systems are able to improve the performance of such a middleware through load balancing and queue provisioning.
The use of message oriented middlewares (MOMs) in the context of the Internet has evidenced a need for highly scalable and highly available MOM. A very promising approach to the above issue is to implement performance management as an autonomic software. The main advantages of this approach are: (i) Providing a high-level support for deploying and configuring applications reduces errors and administrator’s efforts. (ii) Autonomic management allows the required reconfigurations to be performed without human intervention, thus improving the system reactivity and saving administrator’s time. (iii) Autonomic management is a means to save hardware resources, as resources can be allocated only when required (dynamically upon failure or load peak) instead of pre-allocated.
Several parameters may impact the performance of MOMs. Self-optimization makes use of these parameters to improve the performance of the MOM. The proposed self-optimization approach is based on a queue clustering solution: a clustered queue is a set of queues each running on different servers and sharing clients. Self-optimization takes place in two parts: (i) the optimization of the clustered queue load-balancing and (ii) the dynamic provisioning of a queue in the clustered queue. The first part allows the overall improvement of the clustered queue performance while the second part optimizes the resource usage inside the clustered queue. Thus the idea is to create an autonomic system that fairly distributes client connections among the queues belonging to the clustered queue and dynamically adds and removes queues in the clustered queue depending on the load. This would allow to use the adequate number of queues at any time.
A queue is a staging area that contains messages which have been sent by message producers and are waiting to be read by message consumers. A message is removed from the queue once it has been read. For scalability purpose, a queue can be replicated forming a clustered queue. The clustered queue feature provides a load balancing mechanism. A clustered queue is a cluster of queues (a given number of queue destinations knowing each other) that are able to exchange messages depending on their load. Each queue of a cluster periodically reevaluates its load factor and sends the result to the other queues of the cluster. When a queue hosts more messages than it is authorized to do, and according to the load factors of the cluster, it distributes the extra messages to the other queues. When a queue is requested to deliver messages but is empty, it requests messages from the other queues of the cluster. This mechanism guarantees that no queue is hyper-active while some others are lazy, and tends to distribute the work load among the servers involved in the cluster.
Clustered Queue Performance
Clustered queues are standard queues that share a common pool of message producers and consumers, and that can exchange message to balance the load. All the queues of a clustered queue are supposed to be directly connected to each other. This allows message exchanges between the queues of a cluster in order to empty flooded queues and to fill draining queues.
Q c is globally stable when Δl c = 0. This configuration ensures that the clustered queue is globally stable. However Q c may observe local unstabilities if one of its queues is draining or is flooded.
If Δl c > 0, the clustered queue will grow and eventually saturate; then message producers will have to wait.
If Δl c < 0, the clustered queue will shrink until it is empty; then message consumers will also have to wait.
Now, considering that the clustered queue is globally stable, several scenarios that illustrate the impact of client distribution on performance are given below.
A stable and unfair distribution can be observed when the clustered queue is globally and locally stable, but the load is unfairly balanced within the queues. This happens when the client distribution is non-uniform.
It is worthwhile to indicate that these scenarios may all happen since clients join and leave the system in an uncontrolled way. Indeed, the global stability of a (clustered) queue is under responsability of the application developper. For instance, the queue can be flooded for a period; it is assumed that it will get inverted and draining after, thus providing global stability over time.
L i < 1: queue Q i is underloaded and thus lazy; the message throughput delivered by the queue can be improved and resources are wasted.
L i > 1: queue Q i is overloaded and may saturate; this induces a decreased message throughput and eventually leads to thrashing.
L i = 1: queue Q i is fairly loaded and delivers its optimal message throughput.
When L c < 1, the clustered queue is underloaded: if the clients distribution is optimal, then all the standard queues inside the cluster will be underloaded. However, as the client distribution may be non-optimal, some of the single queues may be overloaded, even if the cluster is globally lazy. If the load is too low, then some queues may be removed from the cluster.
When L c > 1, the clustered queue is overloaded: even if the distribution of clients over the queues is optimal, there will exist at least one standard queue that will be overloaded. One way to handle this case is to re-provision the clustered queue by inserting one or more queues into the cluster.
Control Rules for a Self-Optimizing Clustered Queue
[(R 1)] x i > y i : Q i is flooding with more message production than consumption and should then seek more consumers and/or fewer producers.
[(R 2)] x i < y i : Q i is draining with more message consumption than production and should then seek more producers and/or fewer consumers.
[(R 3)] L i > 1: Q i is overloaded and should avoid accepting new clients as it may degrade its performance.
[(R 4)] L i < 1: Q i is underloaded and should request more clients so as to optimize resource usage.
[(R 5)] L c > 1: the queue cluster is overloaded and requires an increased capacity to handle all its clients in an optimal way.
[(R 6)] L c < 1: the queue cluster is underloaded and could accept a decrease in capacity.
Adaptive middleware for message queuing systems helps building autonomous distributed systems to improve their performance while minimizing their resource usage, such as distributed Internet services and distributed information systems.
- 1.Aron M, Druschel P, Zwaenepoel W. Cluster reserves: a mechanism for resource management in cluster-based network servers. In: Proceedings of the 2000 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems; 2000. p. 90–101.Google Scholar
- 2.Menth M, Henjes R. Analysis of the message waiting time for the fioranoMQ JMS server. In: Proceedings of the 23rd International Conference on Distributed Computing Systems; 2006. p. 1.Google Scholar
- 3.Shen K, Tang H, Yang T, Chu L. Integrated resource management for cluster-based internet services. In: Proceedings of the 5th USENIX Symposium on Operating System Design and Implementation; 2002.Google Scholar
- 5.Zhu H, Ti H, Yang Y. Demand-driven service differentiation in cluster-based network servers. In: Proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 2; 2001. p. 679–88.Google Scholar