A Comparison between Task Distribution Strategies for Load Balancing Using a Multiagent System

Abstract

This work presents a comparison between several task distribution methods for load balancing with the help of an original implementation of a solution based on a multi-agent system. Among the original contributions, one can mention the design and implementation of the agent-based solution and the proposal of various scenarios, strategies and metrics that are further analyzed in the experimental case studies. The best strategy depends on the context. When the objective is to use the processors at their highest processing potential, the agents preferences strategy produces the best usage of the processing resources with an aggregated load per turn for all PAs up to four times higher than the rest of the strategies. When one needs to have a balance between the loads of the processing elements, the maximum availability strategy is better than the rest of the examined strategies, producing the lowest imbalance rate between PAs out of all the strategies in most scenarios. The random distribution strategy produces the lowest average load especially for tasks with higher required processing time, and thus, it should generally be avoided.

1. Introduction

Task distribution represents a well-known process that consists in the allocation of tasks, taking into account a set of constraints and factors designed to enhance the capability of the system to handle future tasks. Task distribution has applications in various areas [1], such as cloud computing [2,3], project management [4,5,6,7], edge cloud computing [8,9,10,11,12], etc. A task can take different forms, e.g., a software request, a web request, or an operation in a production process. In order to determine the optimal strategy that maximizes the desired metrics with a minimal impact to the system and its components, one of the solutions is to simulate the process in an isolated environment.

We tackle the task distribution problem as a simulation in the context of a distributed software system modeled using a multi-agent system (MAS), where the processing units are represented by software agents that mimic real processing instances with a specific capability to handle the incoming tasks. Our approach is focused on the evaluation of different task distribution strategies.

With this work, our aim is to study different task distribution strategies and to find possible patterns and correlations between the requirements of the tasks (in terms of needed resources, such as time and processing power) and an optimal method to distribute them. In this way, based on the initial information about the typology of the tasks, the distributor can choose the strategy that has the largest probability to produce the best distribution of the tasks among the processors.

Our main contributions are the following:

• We implemented the software solution that supports the execution of the proposed experiments, with full support for metric definition, task generation, and configuration of processing agents;
• Based on the conducted research, we proposed and implemented a series of distribution strategies in order to have a broader perspective on the relationship between the context, task particularities and the strategy that is suitable in a given scenario;
• We proposed, implemented and evaluated the experiments that are going to be detailed below.

The rest of the paper is organized as follows. In Section 2, we present an overview of the relevant literature, Section 3 details our methodology, in Section 4, we present the results and observations of the proposed experiments, and in Section 5, we include the conclusions and summarize the main findings.

2. Related Work

Task distribution represents a topic given increased attention both in the academic area and in the tech industry, where it is a popular concept from cloud computing known as load balancing (LB) [13,14,15]. Load balancing represents an optimization technique with the goal to find an efficient distribution of the incoming network traffic to a group of servers/processors. Load balancing can be viewed as a particular scenario of task distribution, meaning that beside the general task allocation concept, we analyze the studies and existing approaches focused on this topic, too. We also analyze some of the existing works that focus on comparisons between task distribution methods. We summarize some of these related works and organize them in two sub-sections based on the problem type, i.e., task distribution and load balancing.

In [16,17], the authors survey multiple task scheduling algorithms and compare a large number of scheduling methods. The goals of the two works are similar, but the approaches have some small differences. Both works split the algorithms into multiple categories, but the number and the type of categories differ. Another difference between the two works consists in the criteria that are analyzed during the comparisons and in the algorithms that are compared. Neither of these two studies focuses on the analysis of the tasks used in the experiments and on the impact that a specific method of task distribution can have over the performance of the algorithm, as our work does. In [18], the authors propose a more practical approach, using an existing framework, CloudSim [19], in order to compare six popular, classic task scheduling algorithms [18]. The focus is on analyzing the performance of the algorithms and on inspecting metrics such as: the average waiting time, the turnaround time, load balancing, throughput, and makespan. This study does not explore either the potential impact that the distribution of tasks can have over an algorithm.

2.1. Task Distribution

The authors of [20] tackle the problem of task distribution in a human–machine manufacturing system. To overcome the challenges caused by the stochastic characteristic of the manufacturing systems and the variability and subjectivity of the human operators (which may prefer some tasks over the others, some may work at different paces, etc.), the study proposes a deep reinforcement learning (DRL) approach for this scenario. The proposed system has three types of entities (job, human, and M/C representing the machine) that are described using different specific attributes for each entity. The problem is solved by reinforcement learning (RL) using a partially observable Markov decision process (POMDP) [21] to describe this scenario. In order to enhance the approximation of the Q-value, the authors use a long short-term memory (LSTM) network. They evaluate the proposed strategy with two opposite distribution strategies: first-in first-out (FIFO) that assigns an incoming task to an idle human, without taking into account its level of competence, and the shortest processing time (SPT) that assigns a task to the human with the highest level of competence in solving that task. The proposed solution achieves better results in terms of flow time minimization; a reason stated for the results is that the distribution process is more balanced among operators. The limitations may be caused in scenarios with frequent changes of the operators and machines.

In [22], the authors present an architecture of an MAS solution for scheduling in cloud manufacturing. The approach is based on an extended version of the contract net protocol that encapsulates many-to-many negotiation. The solution takes into account the dynamic arrival of the tasks. The architecture contains ten different types of agents, each with a well-defined role in the system. Only one case study is presented with a particular scenario that is evaluated using the proposed solution. The authors conclude that the case study is sufficient to demonstrate the feasibility of the proposed MAS solution. One may conclude that a single experiment is not enough to demonstrate the effectiveness of the solution, but it is worth taking into account.

2.2. Load Balancing

In the work presented in [14], the authors propose a load-balancing algorithm to solve the task distribution problem in the context of mobile devices in edge cloud computing environments. The proposed method combines the graph-coloring algorithm [23,24] with a genetic algorithm [25,26] that reduces the complexity of the former. The performance of the algorithm is improved compared with the other candidate methods (Cloud First, Round Robin and Priority). In terms of network traffic generation, the proposed algorithm produces the least volume of network traffic, which leads to a lower probability of the network failures to occur. The task waiting time dependency on the number of devices is monitored, showing that better results are obtained for a smaller number of devices, and that, as the number of devices increases, the task waiting time increases, too. The proposed method has better results in terms of average CPU usage of virtual machines (VMs), meaning that it utilizes the edge servers better than other methods. Other optimization algorithms may be tried as well [27,28].

A solution based on ant colony optimization algorithm (ACO) [29,30] enhanced with a nearest-neighbor (NN) distance optimization strategy, is proposed in [31]. This approach is based on three main sequential steps: the preapproval procedure, the NN step, and the ACO step. The preapproval step is executed every time when a new task arrives in order to determine if the task can be processed or not. It consists of verifying whether the node with the maximum available resources is able to handle the incoming task. This step reduces the size of the ACO solutions by rejecting the dissatisfied requests before scheduling. The NN step represents a local search method with the mission to construct the problem graph that will be used by the ants in the ACO step. The nearest neighbor is determined using the Euclidean distance in order to determine which is the nearest node that was not already visited. The objective of the ACO step is to improve the two main factors that influence the decision to choose a processor over the other: the pheromone value for the transition between two nodes and the function that represents the desirability to move from one node to another. The desirability to move between nodes is expressed mathematically using the node resources: CPU, memory and disk utilization. Based on the experiments and comparisons proposed, the authors conclude that the proposed approach outperforms the algorithms that are compared within the majority of scenarios. There is not a clear statement regarding the tasks rejected in the preapproval state, if and how they influence the final metrics and comparisons.

Multi-agent reinforcement learning (MARL) is the method experimented in [32], which tries to distribute the network load in data centers. The authors try to overcome the time bounded distribution decision that should be handled at microseconds level, given the fact that the load balancer (LB) operates at the network level. Their approach consists of transposing the network load-balancing problem into a cooperative game in order to combine the advantages offered by the reinforcement learning (RL) algorithms: capacity to learn in an environment with partial observations and the ability to make decisions in a timely manner for the problem. The framework used to formulate the problem is a decentralized partially observable Markov decision process (Dec-POMDP) [21]. In order to solve the problem, the authors compare three different RL methods: centralized training and decentralized execution (QMIX algorithm [33]), centralized training and centralized execution (SAC algorithm [34], which is a single agent game) and independent agents (I-SAC method) comparing them to the state-of-the-art LB heuristic methods, such as: ECMP [35], WCMP [36], AWCMP [37], LSQ [38] and SED [39]. The benchmarks show that in moderate-scale systems, the QMIX algorithm is superior in the majority of the scenarios, while in large-scale systems, QMIX and I-SAC have a performance closer to the best heuristic methods. Although the results are promising, the authors underline the potential improvements that can be made such as: reducing the cost of communication between the agents during training, unexplored scoring mechanisms and the limitations of the QMIX algorithm.

In general, dynamic environments where task allocation is a requirement can benefit from multi-agent modeling, where the solution can be found in a cooperative manner. A recent review [40] studies the effectiveness of such cooperative control strategies in various application domains focusing on the trade-off between exploration and exploitation. In order to create flexible, effective solutions, the correct balance between these two kinds of behaviors needs to be reached during the operation of the system. For such an objective, reinforcement learning or multi-agent reinforcement learning (MARL) algorithms can be beneficial. Such techniques have proven to be valuable for applications related, e.g., to Internet of Things blockchain-enabled networks [8].

3. Methodology

Inspired by the work completed so far in this area, we decided to perform an in-depth study of task distribution and load balancing. Motivated by the desire to experiment and discover correlations between the specifications of the tasks and the distribution strategy, we propose a system that emulates all the needed actors in the context of the problem under consideration.

3.1. Problem Description

Our objective is to compare and analyze the performance of different task distribution methods in the context of different distributions of tasks in terms of required resources. Before going into more details regarding the system and the distribution strategies, a description of the problem is presented. The problem consists of distributing a known list of tasks to a certain number of processors. The participants, as well as the system, work based on a set of assumptions:

• All the processors are available to receive tasks from time zero of the simulation;
• Each processor has an available processing power that is 100% at the beginning of the simulation;
• Each processor is able to process multiple tasks at the same time;
• The time needed to process a task does not change based on the load of the processor;
• Each processor is able to spawn a certain number of helper processors;
• Each helper processor has a reduced processing power compared to the main processors;
• The list of tasks is available from time zero of the simulation;
• Each task from the list has two requirements: the processing power needed and the time needed for the task to be processed;
• The tasks do not have priorities;
• The tasks are distributed sequentially in the order in which they are placed in the distribution queue.

3.2. System Description

This section contains an in-depth description of the entities that are part of the system together with the communication protocol used and the states of the task distribution process.

3.2.1. System Structure

We implemented the system as a turn-based environment with the communication between the agents handled using the ActressMas framework [41]. The entities of the system, shown in Figure 1, are presented below:

• Environment represents the place where simulations run. This component is responsible for generating the rest of the agents based on the specified configurations;
• Manager Agent generates the tasks to be distributed and communicates with the dispatcher agent to stop the simulation after the distribution of the tasks;
• Dispatcher Agent is the component that handles the communication with the processor agents in order to apply the distribution strategy and to distribute the tasks in the queue;
• Processor Agent (PA) or worker agent is responsible for receiving tasks and processing them, possibly assisted by the helper agents;
• Helper Agents (HAs) are occasionally spawned when a processor agent needs to be assisted in processing a task for which it does not have sufficient resources. Each processor agent is able to spawn a predefined number (the same for all the processor agents) of helper agents that will be alive until the task that they were spawned for is finished.

3.2.2. Task Distribution Process

The decision process of the dispatcher agent can be modeled as a state diagram illustrated in Figure 2. A brief description of each state and of the transitions between them is further detailed:

• State 1: If the task queue contains some tasks, the distributor agent selects the first task (or more tasks, depending on the distribution strategy) and broadcasts it to all the PAs. If no task is available, the dispatcher remains in the current state, waiting for a task to appear in the queue;
• State 2: After collecting the responses from the PAs, the dispatcher agent distributes the task(s) to the PA selected based on the distribution strategy and returns to the first state. If there is no PA available to handle the task(s), the dispatcher goes to next state;
• State 3: In this state, the dispatcher broadcasts a message to all the PAs, requesting the HAs availability;
• State 4: If the dispatcher reaches this state, the best scenario happens if the task can be processed by a PA with the help of its corresponding HAs. After the successful distribution, the dispatcher is ready to go to the first state in order to try the distribution of another task. If there is no PA able to handle the current task even with the help from HAs, then the distributor goes back to the first state, retrying the whole process with the current task. The number of retries is empirically chosen to be 3. If the task reaches the maximum number of retries, it is added to the end of the queue and the dispatcher goes to the first state.

3.2.3. Communication Protocol

The communication protocol that enables the task sharing between the dispatcher agent and the processor agents is an adaptation of the contract net protocol (CNP) [42]. The flow of the messages is presented in Figure 3 and shows what type of messages the agents exchange and the order of those messages in the system.

The information exchanged through the messages and the type of the messages is detailed as follows:

• Work Request (WR) represents the message broadcast by the dispatcher to PAs with details regarding the current task(s) that need(s) to be processed;
• Work Availability (WA) is the response sent by each PA agent and contains information about the available processing power that a PA agent has;
• Work Confirmation (WC) is the message sent by the dispatcher after applying the distribution strategy in order to determine the PA designated to process a given task. The message only contains the ID of the task, and it is sent only to the PA selected to handle the task. The other participant PAs do not receive any rejection message;
• Spawn Request (SR) is the message sent by the dispatcher if there are no available PAs to handle the current task. It is similar to the WR message and requests the availability of the PAs but this time taking into account the availability of the HAs too;
• Spawn Availability (SA) is sent by PAs and offers information about the availability but taking into account also the potential of the HAs;
• Spawn Confirmation (SC) is the message sent by the dispatcher to a PA after the distribution strategy is applied, and the PA selected to handle the task with the help of its HAs is determined.

Compared to the CNP, the communication protocol that we use presents some similarities:

• The presence of the two main classes of participants in the communication process: one that initiates the dialogue and calls for proposals, and the other one that receives the message, analyzes the requirement and responds to the proposal;
• The flow of the messages is similar, following the main pattern of the CNP with “request–response” messages.

However, our implementation has some particularities when compared to the standard CNP:

• The PAs do not send a reject message if the requirements from the Dispatcher cannot be fulfilled. The PAs send only a single type of message that is not specifically a reject or a proposal, but it is an informative message with the current availability of the agent;
• The Dispatcher does not send a specific reject message to the PAs that were not selected to process the request;
• The PA that was selected to process the request does not send a confirmation or a cancel message to the Dispatcher;
• The protocol supports a different round of messages exchanged between the agents in some scenarios.

An important mention related to the system is that we consider it “ideal”, meaning that the communication between the agents happens without data loss, and an agent cannot become unresponsive. Taking into account this property of the environment, the specific confirmation and rejection messages are not mandatory in order to certainly know the state of the agent that sent a message.

Since the term “task” is often used, a description of its main attributes is presented below:

• UniqueId or task name represents a unique identifier used for each task;
• Required Load is a numeric value that represents the number of resources required for a PA in order to process a task;
• Required Time represents the value that measures how long a PA will process the current task.

3.3. Distribution Strategies

Our work evaluates different distribution strategies in different scenarios. The description of the scenarios and the results will be detailed in Section 4. In this section, the focus is on presenting each strategy that is used during the proposed experiments.

3.3.1. Round Robin

The Round Robin strategy is one of the most used strategies in task distribution and load-balancing problems, which was widely used both in academic studies [43,44] and in the cloud industry by the cloud solutions providers [45,46].

Our implementation of the algorithm is based on some initial assumptions, such as: each PA has a unique identification attribute (i.e., name, in our case); the unique identification attribute is used in order to keep the PAs list ordered by that attribute. An illustration of the distribution process is presented in Figure 4 and illustrates the distribution process at two random moments in time. For this example, the names of the PAs are considered to be: PA 1, PA 2, PA 3, and so on. The green PAs are the ones with available resources to handle the current task, and the gray PAs are the ones that do not have sufficient processing capacity to handle the task. At step j, it can be observed that the current task is distributed to the first agent that has sufficient processing power to handle the task, which in this case is PA 1. At the step j + 1, the task is distributed to the next available PA from the list, in ascending order of names. The Round Robin strategy does not take into account any optimization.

3.3.2. Max-Utility

The Max-utility strategy is used to distribute the tasks in order to maximize the utility of an individual PA. The assumption regarding the utility of a PA is that the utility produced by a task is higher if the resources needed to process the task are higher. In other words, the task that produces the greatest resource consumption for a PA is assigned to that PA.

The process of distributing tasks using this strategy consists of broadcasting a task to all the PAs and gathering information regarding their available resources. Based on the list received from the PAs with the available processing resources, the dispatcher agent assigns the task to the processor with the highest utility produced by the current task. If there are many PAs with the same utility produced by the task, then the processor is randomly selected.

3.3.3. Max-Availability

This distribution strategy focuses on the PA with the highest percentage of available resources when distributing a task. The strategy does not take into account the utility produced or any other potential optimizations, even if this means that a task with a lower amount of required resources will be distributed to the PA with the highest availability and the next task to be distributed could remain unassigned because of the counterproductive distributions from before. As in the max-utility strategy, if there are multiple PAs with the same availability, the PA is randomly selected.

3.3.4. Random

In this distribution strategy, the dispatcher agent tries to arbitrarily assign one task to one of the available agents. By available agents, we refer to the group with at least one PA with the available processing power higher than 0. If the randomly selected PA does not have enough resources to process the incoming task, then the distributor agent asks the PA to check for the availability of its HAs. If the PA is able to handle the task assisted by its HAs, then the task is marked as assigned and the next task is picked up to be distributed. If the PA can’t handle the task even with assistance from its HAs, a new random PA is selected and the process is retried.

3.3.5. Agents Preferences

This strategy is inspired by the ranked preference matching algorithms [47,48] without being an exact implementation of a specific algorithm. The main idea of this strategy is focused on matching the PAs with the tasks that produce the greatest utility for them but correlated with the other PAs’ preferences.

One particularity of this method is that there is not only a single task to be distributed but a list of tasks that is broadcast to the PAs. The number of tasks to be distributed is equal to the total number of PAs, or it is lower if the task queue does not contain a number of tasks equal to the total number of PAs. After the PAs receive the list of proposed tasks and analyze the utility that those tasks produce, each PA sends the list of preferences back to the dispatcher, which is sorted in descending order by the utility produced by the tasks. The dispatcher agent gathers the lists of preferences from each PA and merges them in a single list sorted in descending order of the utility produced by each task. This step of the algorithm is presented in Figure 5. An important mention is that when the same task produces the same utility for different agents, the agent–task–utility tuples are placed randomly in the list, not ordered by a specific criterion (such as agent name or task name), as it is highlighted with green in the aforementioned figure.

After the preparation step, once the list of task preferences is created, the next step is an iterative process that is presented in Figure 6. At each iteration, the first tuple from the list is selected (illustrated by the green tuple in the figure) and moved to a helper list; then, all the tuples that contain either the name of the PA from the selected tuple or the name of the task are removed (illustrated with red in the figure). This process is repeated until the task preferences list is empty, meaning that all the PAs have a task ready to be assigned to them.

3.4. Metrics Description

In the next section, the results of the conducted experiments will be presented and detailed. For a better understanding of what the results represent and how those values are obtained, in this subsection, the variables used and the metrics computed are introduced and described. An important mention is that in order to produce statistically valid results, each experiment is executed multiple times, and the generated metrics are scaled based on the number of executions. Another important mention in order to avoid confusions is that the term “turn” should be perceived as a time unit and it is different from the term “simulation step”, which represents one complete execution of the experiment. The notations are described in

Table 1. The parameters used in the calculation of the metrics.

The Number of Simulation Steps	${\mathit{n}}_{\mathit{s}}$
The number of processor agents	$n_p$
The maximum number of helper agents	$n_h$
The list of all processor agents	A
The list of all tasks	T
The list of loads per simulation step j for a given PA, $A^i$	$L_i^j$, i = $\overline{1,n_p}$, j = $\overline{1,n_s}$
The list with number of HAs per simulation step j for a given PA, $A^i$	$H_i^j$, i = $\overline{1,n_p}$, j = $\overline{1,n_s}$
The required processing power for a given task $T^i$	$T_p^i$, i = $\overline{1,\left|T\right|}$
The required time (turns) for a given task $T^i$	$T_t^i$, i = $\overline{1,\left|T\right|}$

and

Table 2. Computed metrics: parameters and their meaning.

The Average Load per Turn for One PA, ${\mathit{A}}^{\mathit{i}}$ (%)	${\mathit{l}}_1^{\mathit{i}}$ = $\frac{1}{{\mathit{n}}_{\mathit{s}}}$ ${\displaystyle \sum _{\mathit{j}=1}^{{\mathit{n}}_{\mathit{s}}}}$ ${\mathit{L}}_{\mathit{i}}^{\mathit{j}}$, i = $\overline{1,{\mathit{n}}_{\mathit{s}}}$
The average load per turn aggregated on all PAs (%)	$l_p$ = $\frac{1}{n_p}$ ${\displaystyle \sum _{i=1}^{n_p}}$ $l_1^i$
The maximum difference between PAs average load per turn	${\delta }_p$ = max($l_1^i$) − min($l_1^i$), i = $\overline{1,n_s}$
The number of turns with at least one HA per turn for a PA, $A^i$	$t_1^i$= $\frac{1}{n_s}$ count($H_i^j$), i = $\overline{1,n_p}$, j = $\overline{1,n_s}$
The average number of turns with at least one HA per turn	$t_1$= $\frac{1}{n_p}$${\displaystyle \sum _{i=1}^{n_p}}$$t_1^i$
The average number of HAs per turn for a PA, $A^i$	$t_a^i$= $\frac{1}{n_s}$$\frac{1}{|H_i|}$${\displaystyle \sum _{j=1}^{n_s}}$$H_i^j$, i = $\overline{1,n_p}$,
The average number of HAs per turn aggregated on all PAs	$t_a$= $\frac{1}{n_p}$${\displaystyle \sum _{i=1}^{n_p}}$$t_a^i$
The average required processing power per task	${\theta }_p$= $\frac{1}{n_s}$${\displaystyle \sum _{i=1}^{\left|T\right|}}$$T_p^i$
The average required time (turns) per task	${\theta }_t$= $\frac{1}{n_s}$${\displaystyle \sum _{i=1}^{\left|T\right|}}$$T_t^i$

.

The metrics used in the experimental studies appear to be relevant for the assessment of the results. However, an empirical approach can open the possibility of optimizing the wrong metric. This is in a way similar to using an inappropriate reward function in multi-agent reinforcement learning, which can lead to agents learning incorrect strategies. For example, in some games, improper reward functions can cause the agents to behave in ways that can be exploited by opponents. Therefore, such reward functions can also be learned from observed behavior in a supervised fashion using, e.g., inverse reinforcement learning. In our case, it must be mentioned that the implemented system allows the addition of other metrics in a straightforward manner. This can alleviate the risk one faces when trying to optimize an imperfect metric. If several different metrics show consistent performance, this increases the chances that the results are indeed valid.

4. Experimental Results and Discussion

This section includes descriptions of the conducted experiments and discussions regarding the obtained results.

The tasks used during the simulations do not have priorities and are randomly generated, varying the attributes of the tasks; the most important are the required resources, i.e., the processing power and time. The limits of the intervals that determine the needed resources were empirically chosen and varied in such a way that numerous scenarios are covered.

When the distribution strategies are compared, in order to have the same conditions and to provide an accurate comparison of the strategies, the same list of tasks is used for all distribution methods in a certain configuration of required resources. In this way, the potential questions and doubts regarding the fairness of the comparison between the distribution strategies are eliminated.

All the experiments are executed with various configurations; however, some parameters remain unchanged throughout the experiments. A summary of the parameters and their values are listed below:

• The number of tasks that are used in the experiments is 500;
• The number of simulation steps is 50;
• The number of PAs is always 5. The processing power of a PA is 100 (this can be regarded as 100% available processing power);
• The maximum number of HAs per PA is 3. The capacity of one HA is 5. In other words, one HA is able to handle 5% of the total available processing power of a PA;
• The minimum and maximum task times (the time is expressed as the number of turns) are varied to produce 3 intervals: [1; 5] (small processing time required), [3; 15] (broad processing time required), and [10; 15] (large processing time required);
• The minimum and maximum task resources required represent the numbers that show how much the availability of a PA will decrease after the task will be accepted. As for the time required, these are varied to produce 3 intervals: [1; 20] (small number of resources required), [1; 40] (broad processing power required), and [20; 40] (high processing capacity required).

The results that will be further presented represent an average of 50 runs, which represent the number of simulation steps.

In order to keep the tables with results more compact, the metrics will be referred to as defined in Table 2, and some abbreviations will be used for the distribution strategies, namely:

• Agents preferences (AP);
• Max-utility (Mu);
• Max-availability (Ma);
• Random (Rnd);
• Round Robin (RR).

4.1. Description of Results

In this section, the results obtained during the simulations are centralized and presented in

Table 3. Statistics for tasks with a low amount of required processing power and various required times.

Metrics	Task Times	Task Loads = [1; 20]
		Distribution Strategy
		AP	Ma	Mu	Rnd	RR
${\delta }_p$	[1; 5]	1.76	0.21	0.66	0.21	1.14
	[3; 15]	6.45	0.25	9.47	0.60	4.04
	[10; 15]	3.91	0.36	9.07	0.81	4.36
$l_p$	[1; 5]	24.19	4.93	4.93	4.93	4.93
	[3; 15]	72.95	16.85	16.83	16.84	16.90
	[10; 15]	86.73	23.79	23.67	23.63	23.76
$t_1$	[1; 5]	-	-	-	-	-
	[3; 15]	-	-	-	0.06	-
	[10; 15]	0.34	-	-	0.55	-
$t_a$	[1; 5]	-	-	-	-	-
	[3; 15]	-	-	-	0.20	-
	[10; 15]	1.40	-	-	1.67	-

,

Table 4. Statistics for tasks with a variable amount of required processing power and various required times.

Metrics	Task Times	Task Loads = [1; 40]
		Distribution Strategy
		AP	Ma	Mu	Rnd	RR
${\delta }_p$	[1; 5]	1.19	0.36	1.11	0.18	2.05
	[3; 15]	3.30	0.51	4.59	1.35	5.02
	[10; 15]	4.80	0.69	0.75	3.44	10.41
$l_p$	[1; 5]	48.69	10.12	10.11	9.79	10.12
	[3; 15]	87.53	31.69	31.57	25.53	30.38
	[10; 15]	88.43	48.40	48.35	32.52	46.34
$t_1$	[1; 5]	-	-	-	0.35	-
	[3; 15]	8.86	-	-	14.72	-
	[10; 15]	51.61	-	-	44.43	-
$t_a$	[1; 5]	-	-	-	1.51	-
	[3; 15]	2.52	-	-	1.78	-
	[10; 15]	2.66	-	-	1.90	-

,

Table 5. Statistics for tasks with a high amount of required processing power and various required times.

Metrics	Task Times	Task Loads = [20; 40]
		Distribution Strategy
		AP	Ma	Mu	Rnd	RR
${\delta }_p$	[1; 5]	1.28	0.21	2.31	0.78	2.29
	[3; 15]	3.18	0.72	1.13	2.72	8.72
	[10; 15]	3.43	0.58	2.54	2.80	6.05
$l_p$	[1; 5]	67.37	14.77	14.77	14.03	14.77
	[3; 15]	87.08	48.91	48.83	29.22	43.62
	[10; 15]	89.44	69.04	70.18	37.28	64.85
$t_1$	[1; 5]	-	-	-	0.70	-
	[3; 15]	29.14	-	-	38.01	-
	[10; 15]	80.44	11.88	1.44	89.20	-
$t_a$	[1; 5]	-	-	-	1.54	-
	[3; 15]	2.76	-	-	1.93	-
	[10; 15]	2.67	1.02	2.32	1.93	-

,

Table 6. Average required processing power per task for a given dataset configuration.

Task Times	Task Loads
	[1; 20]	[1; 40]	[20; 40]
$[1;5]$	9.78	19.6	29.52
$[3;15]$	10.16	19.78	29.51
$[10;15]$	10.14	20.49	29.68

and

Table 7. Average required time (turns) per task for a given dataset configuration.

Task Times	Task Loads
	[1; 20]	[1; 40]	[20; 40]
$[1;5]$	2.55	2.55	2.52
$[3;15]$	8.39	8.27	8.50
$[10;15]$	11.90	11.98	12.10

, which contain the following metrics: the average load per turn aggregated on all PAs ($l_p$), the average number of turns with at least one HA per turn ($t_1$), the average number of HAs per turn aggregated on all PAs ($t_a$), and the maximum difference between PAs average load per turn (${\delta }_p$) in all combinations of task loads and times. Table 6 and Table 7 describe the average values of the required processing power (${\theta }_p$) and time (turns, ${\theta }_t$) for the lists of tasks used in the experiments. The cells where the values are missing (“-”) are present in the sections related to the number of HAs and show that for that specific scenario, no HA was spawned.

4.2. Analysis and Interpretation of Results

Analyzing the average load per turn in Table 3, Table 4 and Table 5 and the average processing power required per task in Table 6, we observed the following correlations between the mentioned metrics. For the agents preferences strategy, in all combinations of required times and loads, the average load per turn for a PA is at least 2.5 times higher than the average processing power required by the tasks, e.g.,:

• The average required processing power per task of 9.78 produces an average load per turn equal to ≈24.2, meaning that the average load per turn is ≈2.49 times higher than the average processing power required per task;
• The average required processing power per task of 19.6 generates an average load per PA equal to ≈48.7, which means that the average load per PA is ≈2.48 times higher than the average required processing per task;
• The average required processing power per task of 29.52 results in an average load per PA equal to ≈67.4, resulting in an average load per PA ≈2.28 times higher than the average processing power required by a task.

For the rest of the strategies from Section 3.3.1, Section 3.3.2, Section 3.3.3 and Section 3.3.4, the analysis revealed that the average load per turn for a PA is ≈2 times lower than the average processing power required by a task (applicable only for the scenarios with tasks with a low required processing time), e.g.,:

• The average required processing power per task of 9.78 produces an average load per turn equal to ≈4.93, resulting in an average load per turn ≈1.98 times lower than the average required processing power per task;
• The average required processing power per task of 19.6 generates an average load per PA equal to ≈10.12, resulting in an ≈1.93 times difference between the two;
• The average required processing power per task of 29.52 results in an average load per PA equal to ≈14.7, generating an ≈2 times difference between them.

To support our statement related to the relationship between the average load per turn for a PA and the average processing power required by a task, we extracted related data from Table 3, Table 4, Table 5, Table 6 and Table 7 and generated a visual representation of the correlation between the average processing power per task and the time increase based on the distribution strategy.

In Figure 7, we present a visual interpretation of how the average load per turn behaves in scenarios with increases of the required processing power per task and required processing time per task for the already mentioned distribution strategies. As the average loads per turn for all the strategies except agents preferences are similar (with some differences for the Random strategy, which is reduced by the presence of HA), we grouped Max-utility, Max-availability, Random and Round Robin in the same category, which is referred to in Figure 7 as “other strategies”. The analysis of the figure highlights the difference in how the average load per turn evolves in the aforementioned strategies.

For the agents preferences strategy, the gap between the values of the average load per turn for different configurations of the tasks required resources is decreasing as the tasks requirements are increasing. For the other compared strategies, the differences between the average load per turn remain constant with the increase of the tasks required resources. This behavior is explainable by the distribution logic of the discussed strategies. The agents preferences strategy is focused on maximizing the utilities of each PA, so as one of the two required resources (time and processing power) is increasing, this will produce an increase in the average load per turn. For the rest of the strategies, taking into account that the distribution process is not directly focused on the utility improvement and that the approaches have similarities from the perspective of the presence of a random factor, the differences in the average load per turn remain constant as one of the required resources increases and the increase of the average load per turn is proportional with the increase factor of the required resource.

Analyzing the data from Table 3, Table 4 and Table 5 with the focus on the maximum difference between PAs average load per turn (${\delta }_p$), we present our main findings in the following paragraphs.

The Max-availability strategy is the one that obtained the best results in terms of minimizing the difference between the PAs in all scenarios except for one (tasks with small processing time required and broad required processing power). Based on our experiments and comparisons, the Max-availability strategy is the most suitable (compared with the presented strategies) for scenarios where the load difference between the PAs has to be minimized.

Another finding is related to the impact of the increase in the resources required by the tasks, i.e., processing time and processing power. Analyzing the aforementioned tables, we observed that the increase of the required processing time tends to produce a higher difference between the PAs’ average load than the increase of the required processing power. This can be explained as follows: a higher processing time in combination with one of the proposed strategies may lead to scenarios with fewer tasks to process for a PA or new tasks received after a long period of time (proportional with the task processing time), leading to a decrease in the average processing time and causing bigger gaps to appear between the PAs.

The analysis of the metrics related to the presence of the HAs in the simulations leads to the following findings.

The Round Robin strategy is the only one that does not need to spawn any HA during the simulations. This can be explained because the way in which the method works, as described in Section 3.3.1, combined with the parameters used for the tasks duration and required processing power drastically reduces the probability to have a scenario where HAs would be needed.

Another important aspect is the behavior in case of using the Random distribution strategy. As the task requirements start to increase (both time and processing power required), the usage of the HAs increases, too. The average load per turn remains lower compared to the rest of the strategies, but the increased presence of the HAs compensates. Taking into account the fact that the average number of HAs per turn is lower than the same metric in the context of the agents preferences strategy, the relatively high presence of the HAs can be explained by the arbitrary character of the distribution.

The statistics related to the HAs produced by the agents preferences strategy indicates that the HAs are used up to the maximum potential, taking into account not only the high number of turns with at least one HA active but also the rate of HAs per turn for the turns with active HAs. This happens due to the focus of the PAs to maximize its own utility.

For the agents preferences method, maximizing the utility of the PAs means that the resources are used in a more efficient way and the energy consumed by the PAs is utilized in a more efficient way. Instead of having machines (PAs) with only a small percentage of the available resources used while consuming the same amount of energy (Max-availability, Max-utility, Random and Round Robin), the agents preferences strategy improves the utility of the PAs, which come with the overall benefit of optimizing the energy consumption.

Some findings related to the dependency between the strategy used and the system behavior are presented. Agents preferences is the most suitable strategy if the request is to maximize the usage of the system’s processing resources, while the other strategies need tasks with increased requirements in order to use more processing resources of the system. In terms of obtaining a balance between all the processors of the system, the strategy that minimizes the differences between the processors, based on the results obtained in our simulation, is the Max-availability strategy. In addition to the impact of the strategies over the system, it is worth mentioning the impact that the distribution of the tasks can have over the results of a distribution strategy and hence over the system. For example, the tasks with an increased processing time required produce a higher imbalance between the system’s processors than an increase in the required processing power.

4.3. Brief Summary of Results

In scenarios when the objective is to use the processors at their highest processing potential (higher load rate for the processors), the agents preferences strategy described in Section 3.3.5 should be the chosen one, as it produces the best usage of the processors resources.

Based only on the analysis of the results related to the PAs, the Random distribution strategy seems to produce the lowest average load per turn among the PAs in all the conducted experiments. Analyzing the statistics related to the HAs for the Random strategy, one may observe that the lower load per turn for the PAs masks a higher load of the HAs, which is a scenario that is easier to observe for tasks with higher required processing time. Thus, the random distribution should be avoided when possible, taking into account its arbitrary behavior.

Based on the results obtained in the conducted experiments, the Maximum Availability strategy described in Section 3.3.3 produced the lowest degree of unbalance between the processors during the simulation. If the requirement is to have a balance between the load of the PAs, the Maximum Availability strategy is better than the rest of the compared strategies.

One of the findings that results from the analysis of the maximum difference between the PAs across different configurations and strategies reveals that the strategy that minimizes the difference between the PAs in 94.4% of the scenarios that we simulate is the Max-availability strategy.

5. Conclusions

In this work, our focus was divided into two parts. First, there is the implementation part where we designed and created the entire system with all the entities, behaviors and metrics described in Section 3, such that we are enabled to proceed with the experimental part. The second part, the experimental one, consists in preparing the simulations, executing the experimental scenarios, recording the results, and analyzing the results with an emphasis on the relation between the characteristics of the tasks and the behavior of the processor agents.

Analyzing the maximum difference between the PAs’ load per turn, the results show that an increase in the time required by the tasks produces a higher imbalance than an increase in the processing power required by tasks.

Moving forward to the analysis of the results related to the HA, one conclusion is that the Round Robin strategy does not need any HAs during the simulations. This happens because of the distribution logic of the method and because the simulation attributes that we proposed lead to a very reduced chance for a PA to need help from a HA, particularly for the Round Robin strategy. Analyzing the strategies with the highest number of HAs spawned, the conclusion is that the Random strategy has a high statistic for the HAs due to the arbitrary character of the method compared to the agents preference where the HAs are spawned by intention by the PAs, maximizing their utility.

The study offers recommendations on which distribution strategy to choose based on the type of the tasks to be distributed and on the expectations from the system (higher load for the processors, minimization of the imbalance between the PAs, etc.). In addition, the study may serve as a starting point to a more in-depth analysis of the task particularities and how these impact the performance of the task distribution process.

The experiments and strategies that we propose address only a small part of the general problem of task distribution. As future work, we intend to add more distribution strategies to be part of the experiments and also to extend the experiments with more varied scenarios of resource type and allocation in order to have a broader view of a variety of scenarios. One limitation is represented by the ideal character of the system, which does not emulate possible faulty scenarios with failing or unresponsive PAs, failover mechanisms to recover from the faulty states, or network disturbances and delays in communication. An analysis of the algorithms in more dynamic scenarios is the next step in our future work. Another limitation is related to the centralized architecture of the system, which does not support a more dynamic environment. In our future investigations, we plan to analyze both fully decentralized and hybrid architectures, i.e., architectures with combined centralized and decentralized features.