Check out the new USENIX Web site. next up previous
Next: The New Servers & Up: Service Inversion Previous: Identifying Service Inversion

Quantifying Service Inversion

While the latency breakdowns by decile qualitatively show the system's unfairness, a more quantitative evaluation of service inversion can be derived from the CDF. We construct the formula based on the following observation: Given responses with sizes . If the observed response times have the same order as the response sizes, we say that no service inversion has occurred, and the corresponding value should be zero. On the contrary, if the response times are in the reverse order of their sizes, then we say that the server is completely inverted, and give it a value of 1.

The insight into calculating the inversion is as follows: we want to determine how perturbed a measured order is, compared with the order of the response sizes. Perturbation is the difference in position of a response in the ordered list of response times versus its position in a list ordered by size, where the per-response distances are summed for the entire list. We then normalize this versus the maximum perturbation possible. A particular service inversion value is given by:


where distance is absolute value of how far the request is from the ideal scenario, and is the total distance of requests in the reverse order of their sizes, which is the maximum perturbation possible. In the above example, assume the observed latency order is . By comparing with the ideal order, , we see the distance of file is 1, is 1, is 2, and $D, E$ are 0. The inversion value is . Since this measurement requires only the response sizes and latencies, as long as the distribution of sizes is the same, it can be used to compare two different servers or the same server at multiple load levels. To handle the case of multiple requests with the same response size, we calculate distance by comparing the $N^{th}$ observed position with the $N^{th}$ ideal position for each response of the same size.

Table 4: Service inversion versus load level
  Relative load level
  0.20 0.40 0.60 0.80 0.90 0.95
Apache 0.14 0.23 0.28 0.51 0.54 0.58
Flash 0.25 0.35 0.45 0.52 0.56 0.58

By measuring service inversion as a function of load level, we discover that this effect is a major contributor to the latency increase under load. Table 4 shows the quantified inversion values for both servers, and demonstrates that while inversion is relatively small at low loads, it exceeds half of the worst-case value as the load level increases. The latencies at the higher load levels therefore not only suffer from queuing delays, but also service inversion delays from blocking. We will show in the next section that the delays stemming from blocking and service inversion are in fact the dominant source of delay.

next up previous
Next: The New Servers & Up: Service Inversion Previous: Identifying Service Inversion
Yaoping Ruan