RT-LaxityBased

RT-LaxityBased algorithm is a request-aware dispatching scheme where requests are mapped to executors based on the laxity property of a request. The other three proposed algorithms only make use of the laxity in the schedulability check when the possibility of achieving the execution deadline of a request is checked with the selected executor. RT-LaxityBased uses the laxity property furthermore in its selection of an executor for a request.

One outcome of the schedulability check is the range of laxities it results in at each ex- ecutor. Having such a mix of laxities paves the way for more requests with overlapping lifespans to be scheduled together. This is achieved by delaying or phasing out the exe- cution of requests with higher laxity values, making way for requests with lower laxities to be scheduled within their time frame. RT-LaxityBased aims to better this process by keeping track of the laxities assigned to each executor. It works by storing the last two laxity values assigned to each executor and preventing requests with the same laxity values being assigned to the same executor consecutively. Moreover, it keeps track of the last executor to have a request assigned to and considers a different executor for the next request. This process leads to an increased range of laxities at an executor and enables more requests to be scheduled together.

Algorithm4, describes the steps in RT-LaxityBased. Upon the arrival of a request, its laxity is calculated (Line 1). It is checked to ensure not to be one of the last two laxities assigned to the executor (Line 3-4). If the laxity is not one of the immediate previous values assigned, the request is checked for schedulability with the last executor (Line 5). If the request could be scheduled successfully (Line 6) it is assigned to the executor (Line 8) after the laxity value is recorded as one of the two values to be successfully assigned (Line 7). If the schedulability check fails, the request is rejected (Lines 9-11).

In the case of the calculated laxity being in the last two laxities assigned to the last executor, next executor in the list is considered (Lines 13-14). The last two laxities assigned to that particular executor is obtained and the calculated laxity is checked against them (Lines 16-17). If it is found to be one of them as well, the process continues on to consider subsequent executors in the list until a match is found (Line 13). If the laxity is not one of them, the schedulability check is done on the selected executor (Line 18-19) and the request is either assigned to it or rejected based on the result (Lines 19- 24). The first time a request is scheduled through the algorithm, there is no last executor

CHAPTER 4. PREDICTABILITY OF EXECUTION IN WEB SERVICES CLUSTERS

Algorithm 4 RT-LaxityBased

Require: New request R, List of Executors E, Laxity Map LM, Last Executor L Ensure: R assigned to an endpoint or rejected

1. Laxity← (_{R.getExecutionT ime}R.getDeadline ) 2. if lastExec is not∅ then 3. LL← lastExec.LastLaxities 4. if Laxity is not in LL then 5. S← IsSchedulable(R,lastExec) 6. if S = true then 7. lastExec.setLastLaxities(Laxity) 8. Assign R to lastExec 9. else 10. Reject R 11. end if 12. else

13. while E.hasMore() and R is not assigned and R is not rejected do 14. nextExec← E.getNextExec

15. if nextExec is not lastExec then

16. LL← nextExec.LastLaxities

17. if Laxity not in LL then

18. S← IsSchedulable(R,nextExec) 19. if S = true then 20. nextEx.setLastLaxities(Lax) 21. lastExec← nextExec 22. Assign R to nextExec 23. else 24. Reject R 25. end if 26. end if 27. end if 28. end while 29. end if 30. else 31. nextExec← E.getfirstExec 32. S← IsSchedulable(R,nextExec) 33. if S = true then 34. nextExec.setLastLaxities(Laxity) 35. lastExec← nextExec 36. Assign R to nextExec 37. else 38. Reject R 39. end if 40. end if

CHAPTER 4. PREDICTABILITY OF EXECUTION IN WEB SERVICES CLUSTERS

information available. In such a scenario the request is checked for schedulability with the first executor in the list (Lines 30-40). The calculated laxity is recorded as the first laxity to be assigned to that executor (Line 34).

Complexity Analysis of RT-LaxityBased

We assume that executor information and details of last laxities assigned to executors are kept in data structures with linear and constant access time complexities respec- tively. We also assume that dispatching R to the selected executor and confirming the rejection of R to the client is outside of the scope of this algorithm and consider the execution time taken of those steps to be constant.

The best case execution for Algorithm4would be on the arrival of the first request at the system. In which case the condition on line 2 evaluates to be false and the statements 31 to 40 gets executed. As line 32 contains a schedulability check, of which the execution time complexity is known to beO(n) and Ω(1). The rest of the statements within lines

31 to 40 have constant time execution. Therefore the worst case time complexity of lines 31 to 40 can be concluded asO(n). If the condition on line 2 evaluates to true,

the execution can again take two paths at line 4. If it evaluates to true, Line 5 contains a schedulability check and rest of the statements in lines 6 - 11 result in constant time. If the condition on line 4 evaluates to false, line 13 has a while loop that iterates at most equal to the number of executors in the cluster. Note that although there are two conditions at lines 15 and 17, either one of them evaluating to false will result in a loop iteration or a loop exit (when the list of executors has been exhausted). If both conditions evaluate to be true, statements on lines 18-25 will be executed. In which case every statement except for the schedulability check on line 18 would have constant time execution. Note that although the schedulability check on line 18 is within the

while loop, it will only be executed once as the condition on line 17 evaluating to true

will result in the termination of the while loop (due to lines 22 and 24).

Letm be the number of executors in the cluster. Let n be the number of already assigned

requests at the selected executor. LetC(n) be the running time of Algorithm4. Lett1

be the execution time of the laxity calculation on line 1 and the condition on line 2. Let

t2be the execution time of lines 3-4. Lett3be the execution time taken for statements

6-11. Lett4be the time taken for execution of statements 13-17. Lett5be the execution

CHAPTER 4. PREDICTABILITY OF EXECUTION IN WEB SERVICES CLUSTERS

ts be the time taken for the schedulability check on the selected executor with only a

single request assigned to it already. The running time of Algorithm 4can be defined as,

C(n) = t1+ t6+ n(ts) | t1+ t2+ n(ts) + t3| t1+ t2+ m(t4) | t1+ t2+ n(ts) + t5 = t1+ t6+ n(ts) ≤ n(t1+ t6+ ts) | t1+ t2+ n(ts) + t3≤ n(t1+ t2+ ts+ t3) |

t1+ t2+ m(t4) ≤ m(t1+ t2+ t4) | t1+ t2+ n(ts) + t5≤ n(t1+ t2+ ts+ t5)

Given the definition above,C(n) can be considered to be linear. However, it is fair to

assume that the number of executors (m) can be considered ∀m, m < n. Therefore,

the worst case time complexity of Algorithm4isO(n) due to the schedulability check.

Furthermore, its best case time complexity can be conclude asΩ(1).