# Distributed Load-Balancing Method for CCA Parallel Component Applications
## 2 Materials and Methods
### Aggregation of the Computing Nodes
The local computing resource proxy on that node allocates the component instances to each CPU core equally. PCDDB employs a distributed load-balancing algorithm. The core of the algorithm includes updating related tables and allocating component instances. We define the platform resource-management node and the sub-cluster startup node. However, the task allocation requests are passed among computing nodes. Each node selectively accepts parts of the tasks in the request according to the content of the related local table. This avoids the huge increase in load that the management node may incur. Our algorithm is primarily used for task allocation on CPU processors. If there are special requirements for code execution--for instance, if some components containing CUDA code must be deployed on a GPU server, or if some components require a large amount of memory to process a large amount of data--these requirements are recorded in the XML file during the data flow analysis. The load-balancing task manager on the startup node includes these special requirements in the task allocation request. Only qualified computing nodes accept and execute these tasks. The adaptiveness of the method mentioned in this paper is primarily manifested in its ability to deploy and execute a component instance in real time and dynamically, based on the information of low-load nodes within the sub-cluster, when the instance requires deployment and execution. This approach contrasts with the static, one-time deployment strategy employed prior to the entire application's execution. Figure 6: Example of load-balancing algorithm execution. ## 3 Results

To test the effectiveness of the distributed dynamic load-balancing method proposed by PCDDB, we first used CCA tools to create a weather forecast parallel component application based on the Fifth Generation Mesoscale Model (MM5) [17]. This application includes eight large functional modules, and the overall module structure is illustrated in Figure 7.

First, the input data are pre-processed. The Topographic module processes the terrain data to generate the terrain data file. The PREinter module reads the preprocessed data and generates the data required by the Inter module, which interpolates the input data. The Background module analyzes the background field data at the barometric layer. The VERinter module reads the background field data and generates the initial grid data and boundary conditions. The MM5 module produces its forecast using the data obtained from other modules. Finally, the Post module generates visual graphics based on the forecast results. ### Number of Component Instances Completed and Effective Working Time Test

Table 2 lists the location statistics of the parallel components in each module. For example, in the first row of Table 2, within the Pre module, there are nine component calls that appear in the for loops, eight component calls in the while loops, three component calls in the recursive call structures, and five component calls that are not included in these three structures. As Table 2 reveals, most component calls in the application appear in the code structures with simple dependencies. Therefore, these components are highly suitable for parallel execution, aligning well with the load-balancing strategy proposed in this paper. The execution platform we used is a heterogeneous cluster. This platform consists of thirty dual-core servers (Intel Pentium G4520 @ 3.60 GHz, 8 GB memory; nodes 1-30), three 8-core servers (Intel Xeon Silver 4110 @ 2.10 GHz, 64 GB memory; nodes 31-33), and three