## 5 Simulation Experiments and Results Analysis
### Results and Analysis of the Experiment  
This paper selected the CFN [69] and DNS as comparison schemes. The CFN mechanism is the first representative Computing Network scheduling architecture. It locates requests to a single optimal cluster based on the status of computing and network resources, and it uses the TCP/IP network as the underlying technology and operates in a flat architecture. The DNS is another simple and effective load balancing mechanism that selects the target cluster based on weight or randomly selected from several records. Since the DNS lacks service information awareness, this paper simplified the process by assigning weights to candidate nodes based on network conditions so that clusters with better network conditions would be more likely to be selected. It is worth noting that based on the analysis of weighting methods in Section 4.1, it can be inferred that due to the lack of a domain partitioning mechanism in the CFN architecture, each node maintains a larger amount of service information, making the objective weighting method more effective than the subjective weighting method (BWM). Conversely, in the architecture proposed in this paper, the subjective weighting method (BWM) is expected to perform better than the objective weighting method. Subsequent experimental results confirm this. Overall, when the same weighting methods and selection algorithms were applied, the proposed ari \begin{table}
\begin{tabular}{l l} \hline
**Parameter** & **Description** \\ \hline \multirow{3}{*}{Data Set} & [[https://github.com/ailibaba/clusterdata](https://github.com/ailibaba/clusterdata)]([https://github.com/ailibaba/clusterdata](https://github.com/ailibaba/clusterdata)) \\  & (accessed on 1 January 2008) \\  & [[https://qwsdata.github.io/](https://qwsdata.github.io/)]([https://qwsdata.github.io/](https://qwsdata.github.io/))(accessed on 1 January 2018) \\ \hline Number of Edge Network Nodes & 45 \\ \hline Number of Medium Network Nodes & 9 \\ \hline Number of Large Network Nodes & 3 \\ \hline Delay constrains of request & (0 ms, 10 ms], (10 ms, 50 ms], (50 ms, 100 ms] \\ \hline Delay between Edge Network Nodes (in & (0 ms, 1 ms] \\ same domain) & (1 ms, 5 ms] \\ same domain) & \\ \hline Delay between Large Network Nodes (in & (5 ms, 20 ms] \\ same domain) & \\ \hline Number of request & 10/30/60/90/120/150 \\ \hline Number of Service type & 20 \\ \hline Service number of each cluster & 100 (Large)/80 (Medium)/60 (Edge) \\ \hline \end{tabular}
\end{table} 
Table 5: Simulation configurations. rate is the ratio of successfully scheduled service requests to the total number of requests. It is important to note that, to make the experiment more realistic, the service processing delay in this paper was not entirely determined by the historical completion times in the service information. Instead, it simulated the processing of service requests in the cluster using multi-threading after scheduling was completed. The processing speed of the service is related to the current load state of the cluster. If any resource in the cluster (such as CPU or memory) is utilized below 10%, the cluster is considered to be overloaded. Depending on the severity of the overload, the processing delay can increase to four, three, or two times the historical completion time. Regarding transmission delay, each cluster has a threshold limit on the number of services it can provide. When the number of requests exceeds this threshold, the transmission delay increases proportionally based on the excess. Specifically, for each doubling of requests, the transmission delay increases by 2.5% for large clusters, 5% for medium clusters, and 10% for edge clusters. Based on the above experimental design, this paper tested each cluster with service request quantities of 10, 30, 60, 90, 120, 150, and 180 per unit of time. The experimental results are shown in Figure 9.  
Figure 9 presents a comparison of the experimental results between the proposed architecture, CFN, and DNS under the same algorithm.