Shape of the hierarchy

A recurrent question people ask when first using DIET, is how should my hierarchy look like? There is unfortunately no universal answer to this. The shape highly depends on the performances you want DIET to attain. The performance metric that we often use to characterize the performance of DIET is the throughput the clients get, i.e., the number of serviced requests per time unit.

Several heuristics have been proposed to determine the shape of the hierarchy based on the users' requirements. We can distinguish two main studies. The first one focused on deploying a single service in a DIET hierarchy [3,4]. The shape of the best hierarchy on a fully homogeneous platform is a Complete Spanning d-ary tree (CSD tree). The second study focused on deploying several services alongside in a single hierarchy. Heuristics based on linear programming and genetic algorithm have been proposed for different kinds of platform [6,7].

Even though the above mentioned studies can provide good, if not the best, deployments, they heavily rely on modelizations and benchmarks of DIET and the services. This process can be quite long. Thus, we propose in this section a simple but somehow efficient way of deploying a hopefully “good” hierarchy. (Note that if you do not care about performances, a simple star graph should be enough, i.e., an MA and all your SeDs directly connected to it.) Here are a few general remarks on DIET hierarchies:

• The more computations your service needs, the more powerful server you should choose to put a SeD on.
• Scheduling performances of agents depends on the number of children they have, as well as on the number of services each of the child knows. An agent will be more efficient when all its children know one and the same service. Thus it is a good idea to group all SeDs having the same characteristics under a common agent.
• The services declared by an agent to its parent is the union of all services present in its underlying hierarchy.
• It is usually a good idea to group all DIET elements having the same services and present on a given cluster under a common agent.
• There is usually no need for too many levels of agents.
• If you suspect that an agent does not schedule the requests fast enough, and that it is overloaded, then add two (or more) agents under this agent, and divide the previous children between these new agents.