# High-Performance Elastic Management for Cloud Containers Based on Predictive Message Scheduling
## 6 Experiments  
The effect of elastic scalability for cloud containers has been evaluated from multi-aspect experiments. Twenty PC servers are used as the message generator, database servers, and Docker manager servers to build an experimental environment. An E-shop system was chosen as the application test case. The E-shop system is based on the benchmark program of TPC-W (Transaction Processing Performance Council for Web), and Pylot software (V 1.26, Apache Software Foundation, Forest Hill, MA, USA) as the message generator to generate high concurrent load. The E-shop system consists of several modules according to the micro-service framework, such as a shopping service, a logistics service, a transportation business service, a car service, and a business pay service. The configuration of the testing environment of the experiments is shown in Figure 6.  
As the elastic performance improvement is a multi-dimensional characterization, four sets of experiments are set up to verify the effectiveness of our work. Experiment one is to verify the  
Figure 5: Prototype design of Elastic-Docker. SSH2: Secure Shell; API: Application Program Interface; DB: DataBase. Figure 6: Configuration of the experimental environment. throughput evaluation of cloud containers. Experiment two is to verify the prediction accuracy and response delay of the services. Experiment three is to verify the system resource consumption. Experiment four is to verify the elastic scalability of containers. (1) Throughput Evaluation of Cloud Containers  
Experiment one evaluates the throughput of messages in four different ways. The reasons for their changes are tracked and analyzed by observing changes in the amount of messages sent in different ways. There are concurrent messages (the size of batch message is from 20 to 2000) to verify the effectiveness of message queue processing strategy. A single message is sent (every 200 bytes) as the experimental base, experimental data of the message number produced per second are recorded. According to Figure 7, we can see the comparison data of LightDocker (Red Hat Enterprise Linux 7 Atomic Host, Red Hat Inc., Raleigh, NC, USA), Docker (V 1.13, dotCloud, Inc., San Franciso, CA, USA), Docker with Workflow(An prototype system developed in [5]), and Elastic-Docker systems. Figure 8 shows the average experimental results of throughput in the environment. After collecting running data for a period of time, it can be seen from the results that Elastic-Docker system greatly improves the concurrency processing capability compared with original Docker system. As the amount of message generation continues to increase, the message batch number of the Docker with Workflow and Docker grows slowly. As seen from the LightDocker's curve, there is a significant downward trend in the rate of message sending as the messages increase. The main reason is that the simplification of the container mirroring component reduces its processing ability. Elastic-Docker still maintains a low delay when the number of batch messages is 2000, and the throughput improves by 90%. Docker with Workflow curve in Figure 8 shows that the adoption of workflow mechanisms in Docker does significantly improve service efficiency, but when a large number of messages come into the system, the improvement of performance becomes inconspicuous and short. As mentioned above, Elastic-Docker effectively improved the message throughput. (2) Prediction Accuracy and Response Delay of Services  
In Experiment 2, the changes of the message processing delay and the accuracy of the predictive value are compared in four ways to verify the validity of the elastic expansion ability. In order to test the accuracy of the container demand prediction method, different numbers of messages are selected (the size of batch message is from 100 to 1500). The Elastic-Docker system runs with different algorithm for prediction, including Grey prediction, neural network algorithm, and regression analysis algorithm.