國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
35
5. Evaluation
We have conducted a questionnaire survey on the iPalace Video Channel service.
This experiment lasts fifteen days. To simplify the study, we only provide the video service via the DC Collection. In this experiment, we use the average of CPU load instead of the number of arrivals of the corresponding VM handles with as the control variable. We set the average of CPU load as the upper bound to 0.1. The minimal load VM is iteratively selected from the cluster as the candidate for the coming requests.
The Dispatcher did not set to count the number of arrivals of the corresponding VM in this experiment.
In the following discussions, we only report the data from 2012/3/4 00:00 to 2012/3/5 14:12. We do not report the result of Worker 1 (W1) because W1 also works as the Dispatcher while W1 works to provide the video service to users.
Figure 15: Change of the average of CPU load of VMs in the cluster. The X axis is time in minutes and the Y axis is the average of CPU load
Figure 15 shows the change of average of CPU load of VMs in the cluster. The X axis is time denoting the time epoch in minutes. The Y axis is the average of CPU load. A new VM is initiated when the minimal average of CPU load of running VMs in the cluster exceeds 0.1. At the beginning (time 00:00), only W1 in the cluster
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
36
handles all the requests. It lasts 26 minutes and hits the average of CPU load to 0.26;
then a new VM W2 (dark blue line) is invoked to share the workload. As shown in Figure 15, W3 (red line) is invoked at 00:49, W4 (green line) at 04:02 and W5 (purple line) at 14:34. Intervals between a new VM being invoked are 26 minutes, 23 minutes, 3 hours and 13 minutes, and 10 hours and 32 minutes. It is reasonable since that the more running VMs in the cluster, the more load can be taken and the longer the interval between a new VM being invoked.
Another interesting finding from Figure 15 is an observation of load balancing:
that is, the peak load does not accumulate by a certain VM in the cluster. For instance, as shown in Figure 15, the peak load can be appeared at any one of W2, W3, W4 and W5. None of the peak load lasts on a specific VM for a long period of time since the new arrivals are dispatched periodically to a new VM (i.e., another running VM having a lower load or a new initiated VM). The load balance mechanism shows its effectiveness in this setting.However, the peak may be large enough to deteriorate the service quality. Thus, to guarantee an acceptable service quality, we integrate the load balance mechanism with the setting of an upper bound of number of arrivals to be served by a single VM.
Figure 16: Change of packets sent in cluster VMs. The X axis is time and the Y axis is number of packets.
Figure 16 shows the accumulation of the number of sent packets of each VM in the cluster. The X axis is time and the Y axis is the number of packets. When the slope gets sharp, it means that the VM is sending a large amount of packets at that
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
37
moment. One can observe that the VMs are taking turns of the increase, indicating the balance of the workload.
Figure 17 shows the change of requests per second of each VM in the cluster.
The X axis is time and the Y axis is the value of HTTP requests per second. As shown in Figure 17, the value of HTTP requests per second gathered from Apache server is very low (<0.05) due to the nature of video-based service. Compared to the text-based webpage services, there are fewer click-and-responses among the server and the user in the video-based service.
Figure 17: The requests per second in cluster VMs. The X axis is time and the Y axis is value of the requests/second.
Figure 18 shows the change of the number of established connections of each VM in the cluster. The X axis is time in hours and the Y axis is the number of established connections. We have approximate 3 to 8 connections of each VM in the cluster. As shown in Figure 18, the connections are distributed roughly in balance among the VMs in the cluster.
‧
國立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
38
Figure 18: Number of Connections established. The X axis is time in hours and the Y axis is number of Connections established.
In sum, the preliminary result shows some promise of our cluster structure and load balancing algorithms. However, we find out some drawbacks from the result of the experiment. We distribute requests to the corresponding VM so that all the requests come within the period of DURATION will be assigned to the corresponding VM. If requests increase suddenly within the DURATION, it is possible the corresponding VM gets overloaded. Thus, we let the Dispatcher to count the number of arrivals the corresponding VM handing with. When the number of arrivals equals the BOUND – the upper bound of the number of arrivals that each VM can handle with, the Dispatcher will initiate a new VM, add it to the cluster, and update the corresponding VM stated in the internal XML file of the Monitor to select it as the corresponding VM.
Even though we distribute requests to VMs in balance, requests might increase suddenly in the DURATION which may violate the service quality. Because the iPalace Video Channel promise a high-quality and uninterrupted service, everything might violate the service quality is unacceptable. Thus, we design the two phase service system stated in section 4.
Another interesting finding is that the value of the request/second is much smaller compared to the result of the experiment conducted by Adler. Instead of video-based websites, Adler conducts an experiment which focuses on text-based website. It shows the difference of load balancing between video-based website and text-based website. There are a lot of requests in a short time for requesting content in text-based website. However, requests will not be sent again until users request another video in the video-based website. That is why the value of the request/second in video-based website is much smaller than in text-based website.
‧
understand the setting of video-based service provided through the cloud framework.By sampling the service in practice, we also conduct an online experiment for understanding the effect provided through a heuristic mechanism of load balancing.
The theoretical study shows that the service quality of the video-based service depends on the CPU throughout and the bandwidth of network regarding the cloud infrastructure. Intuitively, it comes to mind that the CPU throughout of the server and the client as well as the bandwidth of the network dominate the service quality. The Equation (4) in Section 4 (quantum+max(packagetranstime+delaytime, (BOUNG-1)*
quantum) < playtime) confirms this relationship. It explicitly specifies how the CPU throughout and the bandwidth affect the service quality. Specifically, quantum (the time quantum) and playtime (the time of playing packages generated in a time quantum) both are determined based on the CPU throughout. And packagetranstime (the normal transmission time of packages generated in a time quantum) and delaytime (the transmission delay time) depend on the bandwidth. For different system and network environments, the constraint shows how we adjust the setting to provide smooth video services. If the values of quantum, packagetranstime and delaytime are larger (poor network transmission), we should set the BOUND smaller (so that each VM handles less connections) to avoid potential violation against the service quality. On the other hand, if packagetranstime is larger (a sequence can be displayed a long time on the client side), it is possible that we can set the BOUND larger to allow a VM dealing with more connections simultaneously. Another interesting finding is that theoretically, we can estimate the proper settings to satisfy the service quality given the performance of the computer and network environment (by observing systematical measurement), and hence can be applied to different system environment and architecture. The value of system reliability also can calculate from this equation.
In this paper, we propose that the backstage of the video service – the iPalace Video Channel is under the two phase service system architecture. The service system regarding the phase I is a multichannel, single-phase service system with a variant amount of VMs such that every arrival is served by a VM and there is no balking, and is responsible for receiving the user initial request and responding with the index webpage which directs the user to the corresponding VM. The service system regarding the phase I is a M/D/1: //FCFS queuing system and is designed to satisfy the service quality and accomplish the load balancing mechanism. The service system