## 4 Experiments and Analysis
### Optimal Token Fill Rate Detection  
The task traffic accepted by the Spatio-Temporal Big Data Center is complex and diverse, while the classic token bucket algorithm performs traffic shaping by setting a fixed token fill rate, which is not well-suited for actual demands. To verify this issue, three types of tasks are defined: simple tasks (single-task single-thread execution time \(<\) 10 ms), general tasks (single-task single-thread execution time 10 ms \(\leq\) t \(<\) 50 ms), and complex tasks (single-task single-thread execution time \(\geq\) 50 ms). Service scenarios containing only one of these task types are established, and the optimal token fill rate for the classic token bucket algorithm is explored under multi-task conditions. The experimental set up includes multiple groups of concurrency scenarios, with concurrency levels ranging from 1 to 200, and with each scenario differing by five concurrent tasks. To ensure that the experimental results are statistically significant, 20 experiments will be conducted for each group, and the mean and standard deviation of the experimental results for each group have been tabulated, which are shaded in the figures of the experimental results (by shading the areas around each line). In the scenario of simple tasks, the token fill rate is set to 50 tokens/s, 75 tokens/s, 100 tokens/s, 125 tokens/s, 150 tokens/s, and 200 tokens/s, respectively. In the scenario of general tasks, the token fill rate is set to 50 tokens/s, 100 tokens/s, 200 tokens/s, 300 tokens/s, 400 tokens/s, and 500 tokens/s, respectively. In the scenario of complex tasks, the token fill rate is set to 25 tokens/s, 50 tokens/s, 100 tokens/s, 200 tokens/s, 300 tokens/s, and 400 tokens/s, respectively. The optimal token fill rate is the rate corresponding to the lowest average task completion time (average latency). From Figure 4, it can be seen that for simple task scenarios, setting the token fill rate to 50 tokens/s (orange solid line) results in the highest average latency across various concurrency levels, with a significant increase in latency as concurrency increases. This indicates that such a low rate severely limits system performance, causing excessive tasks to be queued and blocked. As the token fill rate increases to 75 tokens/s, 100 tokens/s, 125 tokens/s, and 150 tokens/s, the average latency progressively decreases, reflecting improved system efficiency. Notably, at a token fill rate of 200 tokens/s (pink solid line), the system achieves optimal performance, with an average latency of approximately 68 ms within a concurrency range of 100 to 200. This demonstrates that 200 tokens/s is the optimal fill rate for minimizing task completion time and ensuring efficient operation under high-concurrency conditions. As shown in Figure 5, for general task scenarios, the average latency increases approximately linearly with the increase in concurrent requests. However, a higher token fill rate does not correspond to a lower average duration for total task completion. The token fill rate corresponding to the lowest average latency is 100 tokens/s  
Figure 4: Detection of optimal token fill rate for simple task scenarios. latency is 50 tokens/s. The average latency at other rates is closer and much higher than that at 100 tokens/s. Delving into the reasons, an excessively low token fill rate constrains the system's processing capability, causing a large number of tasks to be stalled in the queue, whereas an excessively high token fill rate results in an overwhelming system load, pushing the system's processing capability to its bottleneck. Hence, the token fill rate corresponding to the lowest average time is selected as the optimal rate for general task scenarios, which is determined to be 100 tokens/s. At a concurrency level ranging from 100 to 200, the average latency at this optimal rate is 924 ms.  
From Figure 6, for complex task scenarios, the pattern of change in the average latency is similar to that of the general task scenario.