Your SlideShare is downloading. ×
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Achieving Predictability and Service Differentiation in Web Services
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Achieving Predictability and Service Differentiation in Web Services

430

Published on

Achieving Predictability and Service Differentiation in Web Services

Achieving Predictability and Service Differentiation in Web Services

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
430
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Intro Solution Impl. Eval. Conclusion Achieving Predictability and Service Differentiation in Web Services Vidura Gamini Abhaya Prof. Zahir Tari and Assoc. Prof. Peter Bertok Distributed Systems and Networking Group School of Computer Science and IT RMIT University Melbourne, Australia December 16, 2009 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 2. Intro Solution Impl. Eval. Conclusion Agenda 1 Introduction 2 Proposed Solution 3 Implementation 4 Emperical Evaluation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 3. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope What’s Next? 1 Introduction Motivation Real-time Applications Research Goals and Scope 2 Proposed Solution 3 Implementation 4 Emperical Evaluation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 4. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Motivation Research on QoS fails to guarantee predictability in service execution. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 5. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Motivation Research on QoS fails to guarantee predictability in service execution. Assumptions are made on achieving QoS levels. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 6. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Motivation Research on QoS fails to guarantee predictability in service execution. Assumptions are made on achieving QoS levels. WS architectures and supporting infrastructures lack support for predictability. E.g. - SOAP engines and App Servers service requests in a best effort manner. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 7. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Motivation Research on QoS fails to guarantee predictability in service execution. Assumptions are made on achieving QoS levels. WS architectures and supporting infrastructures lack support for predictability. E.g. - SOAP engines and App Servers service requests in a best effort manner. Design goals are to increase throughput by concurrent processing. No. of requests served parallely ∝ Time taken to service a request V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 8. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Motivation Research on QoS fails to guarantee predictability in service execution. Assumptions are made on achieving QoS levels. WS architectures and supporting infrastructures lack support for predictability. E.g. - SOAP engines and App Servers service requests in a best effort manner. Design goals are to increase throughput by concurrent processing. Apps. with real-time requirements cannot make use of web services. Real-time applications ⇒ require predictability V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 9. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Real-time Applications [9] Characteristics V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 10. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Real-time Applications [9] Characteristics Real-time computing = Super Fast computing (Instantaneous) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 11. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Real-time Applications [9] Misconceptions Real-time computing = Super Fast computing (Instantaneous) X Characteristics Predictability! - A correct result obtained too late isn’t useful Speed of execution is less important V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 12. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Real-time Applications [9] Misconceptions Real-time computing = Super Fast computing (Instantaneous) X Characteristics Predictability! - A correct result obtained too late isn’t useful Speed of execution is less important Should not sacrifice the deadline of an important task for the sake of another (even if it has to be rejected) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 13. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Real-time Applications [9] Misconceptions Real-time computing = Super Fast computing (Instantaneous) X Characteristics Predictability! - A correct result obtained too late isn’t useful Speed of execution is less important Should not sacrifice the deadline of an important task for the sake of another (even if it has to be rejected) Examples Nuclear plant control systems, Avionics system, Factory floor control systems V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 14. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Research... Goals - Enable the use of web services as a middleware in applications with real-time requirements - Means of achieving execution time QoS for non real-time applications. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 15. Intro Solution Impl. Eval. Conclusion Motivation Real-time Apps Goals and Scope Research... Goals - Enable the use of web services as a middleware in applications with real-time requirements - Means of achieving execution time QoS for non real-time applications. Scope Supporting real-time applications requires predictability in, - Message processing and service execution - Network communication In the context of this research, only execution level predictability is considered. No transmission delays and contentions are assumed at the network level. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 16. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. What’s Next? 1 Introduction 2 Proposed Solution Introduction of a Deadline Admission Control Schedulability Check Scheduling Algorithm 3 Implementation 4 Emperical Evaluation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 17. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Introduction of a Deadline Definition Absolute time period the request must be serviced within V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 18. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Introduction of a Deadline Definition Absolute time period the request must be serviced within Communicated to the server using SOAP headers V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 19. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Admission Control Challenges 1 No prior information about requests and their arrival 2 Difficult to schedule them to meet deadlines V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 20. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Admission Control Challenges 1 No prior information about requests and their arrival 2 Difficult to schedule them to meet deadlines Therefore... It is impossible to accept all requests and still meet all their deadlines V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 21. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Admission Control Challenges 1 No prior information about requests and their arrival 2 Difficult to schedule them to meet deadlines Therefore... It is impossible to accept all requests and still meet all their deadlines - Only accept requests that we can meet the deadlines - Decision made runtime: based on requested and available CPU time Contribution An on-the-fly admission control mechanism based on real-time scheduling principles V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 22. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Schedulability Check Step 1 Ensure deadline requirement of new task could be met a a (Based on equations 7,8 & 9 of the model) * The execution time requirement of the new task is obtained either as a grouped average of the previous executions or offline profiled execution time V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 23. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Schedulability Check Step 2 Ensure new task does not compromise the deadlines of already accepted tasks a The effect of the new task must be checked individually, on each task finishing thereafter a (Based on equations 10,11 & 12 of the model) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 24. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Scheduling Algorithm Accepted tasks are scheduled in the order of decreasing deadlines (EDF) This ensures all tasks meet their deadline requirement Schedulable bound of EDF is 100% V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 25. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 26. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = (0 + 6)ms = 6ms Proc. Demand After = (0 + 4)ms = 4ms Total Proc. Demand = (6 + 4)ms = 10ms Loading Factor = 10 (25−1) = 0.4167 0.4167 < 1 (Accept Request) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 27. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 3ms (0 + 3) Proc. Demand up to T2 = 3ms (0 + 3) Total Proc. Demand = 7ms (3 + 4) Loading Factor = 7 (20−3) 0.42 < 1 (Continue on to next check) Proc. Demand up to T1 = 8ms (4 + 4) Total Proc. Demand = 11ms (3 + 8) Loading Factor = 11 (25−3) 0.5 < 1 (Accept request) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 28. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 T4 4 4 7 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 2ms (0 + 2) Proc. Demand up to T2 = 4ms (0 + 4) Proc. Demand up to T4 = 6ms (2 + 4) Total Proc. Demand = 10ms (6 + 4) Loading Factor = 6 Loading Factor = 10 (11−4) (20−4) 0.86 < 1 (Continue...) 0.47 > 1 (Continue...) Proc. Demand up to T1 = 8ms (4 + 4) Total Proc. Demand = 14ms (6 + 8) Loading Factor = 14 (25−4) 0.737 < 1 (Accept request) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 29. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 T4 4 4 7 T5 7 2 3 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 2ms (0 + 2) Proc. Demand up to T4 = 3ms (0 + 3) Total Proc. Demand = 5ms (2 + 3) Loading Factor = 5 (11−7) 1.25 < 1 (Reject Request) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 30. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 T4 4 4 7 T5 7 2 3 T6 8 7 10 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 2ms (0 + 2) Total Proc. Demand up to T6 = 9ms (2 + 7) Loading Factor = 9 (18−8) 0.9 < 1 (Continue...) Proc. Demand up to T2 = 4ms (0 + 4) Total Proc. Demand = 13ms (9 + 4) Loading Factor = 13 (20−8) 1.083 < 1 (Reject Request) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 31. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 T4 4 4 7 T5 7 2 3 T6 8 7 10 T7 9 2 6 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 1ms (0 + 1) Proc. Demand up to T2 = 4ms (0 + 4) Proc. Demand up to T6 = 3ms (1 + 2) Total Proc. Demand = 7ms (3 + 4) Loading Factor = 3 Loading Factor = 7 (15−9) (20−9) 0.5 < 1 (Continue...) 0.636 > 1 (Continue...) Proc. Demand up to T1 = 8ms (4 + 4) Total Proc. Demand = 15ms (7 + 8) Loading Factor = 15 (25−9) 0.9375 < (Request Accepted) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 32. Intro Solution Impl. Eval. Conclusion Deadline Admission Control Sched. Check Sched. Algo. Sample Scenario Task ST ET D T1 0 5 25 T2 1 6 19 T3 3 3 7 T4 4 4 7 T5 7 2 3 T6 8 7 10 T7 9 2 6 ST - Start Time (ms) ET - Execution Time (ms) D - Deadline (ms) Schedulability Check calculation Proc. Demand Within = 1ms (0 + 1) Proc. Demand up to T2 = 4ms (0 + 4) Proc. Demand up to T6 = 3ms (1 + 2) Total Proc. Demand = 7ms (3 + 4) Loading Factor = 3 Loading Factor = 7 (15−9) (20−9) 0.5 < 1 (Continue...) 0.636 > 1 (Continue...) Proc. Demand up to T1 = 8ms (4 + 4) Total Proc. Demand = 15ms (7 + 8) Loading Factor = 15 (25−9) 0.9375 < (Request Accepted) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 33. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements What’s Next? 1 Introduction 2 Proposed Solution 3 Implementation Overview System Components Enhancements to Axis2 4 Emperical Evaluation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 34. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements Realising the model Overview Real-life implementation rather than a simulation Enhance existing web services middleware Apache Axis2 - Widely used and Open source SOAP engine Axis2 Java implementation selected V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 35. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements Realising the model Overview Real-life implementation rather than a simulation Enhance existing web services middleware Apache Axis2 - Widely used and Open source SOAP engine Axis2 Java implementation selected Unsuitability of Standard Java for RT Apps. [Wang and Baglodi, 2002] Garbage Collector (GC) can pre-empt any running thread Cannot control when GC runs Priority model doesn’t properly map to OS level priorities Cannot prevent/resolve priority inversions On-demand Just-in-time compilation and class loading V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 36. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements System Components Development Platform Real-time Specification for Java (RTSJ) ver 2.1a Additional thread priority levels mapping to OS priorities Priority levels GC cannot interrupt Pre-emptive Real-time scheduler Ability to compile ahead and pre-load classes a http://java.sun.com/javase/technologies/realtime/ V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 37. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements System Components Development Platform Real-time Specification for Java (RTSJ) ver 2.1a Additional thread priority levels mapping to OS priorities Priority levels GC cannot interrupt Pre-emptive Real-time scheduler Ability to compile ahead and pre-load classes a http://java.sun.com/javase/technologies/realtime/ Operating System Sun Solaris version 10 update 08/05 High-precision clocks Hooks for dev platforms to use RT features V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 38. Intro Solution Impl. Eval. Conclusion Overview Components Enhancements Enhancements to Apache Axis2 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 39. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. What’s Next? 1 Introduction 2 Proposed Solution 3 Implementation 4 Emperical Evaluation Summary of Results Execution time Comparison CPU Utilisation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 40. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Experimental Results Metrics - Percent. of tasks accepted by RT-Axis2 - Percent. of deadlines met by RT-Axis2 and Unmod. Axis2 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 41. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Experimental Results Metrics - Percent. of tasks accepted by RT-Axis2 - Percent. of deadlines met by RT-Axis2 and Unmod. Axis2 Comparison of RT-Axis2 and Unmod Axis2 Real-time Axis2 Unmodified Axis2 Distribution Inter-arrival % Acc. % D. Mis. % D. Met % D. Mis. % D. Met time(sec) 0.25 - 5 41.8 0 100 96.6 3.4 Uniform 0.25 - 10 81.2 0 100 83.6 16.4 Bnd. Expo. 0.25 - 2 62.5 0.1 99.9 42.6 57.4 0.25 - 5 99.3 0 100 0 100 λ = 10−6 0.25 - 10 100 0 100 0 100 Bnd. Expo. 0.25 - 2 100 0 100 0 100 0.25 - 5 100 0 100 0 100 λ = 10−5 0.25 - 10 100 0 100 0 100 0.25 - 2 100 0.3 99.7 0 100 Bnd. Pareto 0.25 - 5 100 0.1 99.9 0 100 α = 0.5 0.25 - 10 100 0 100 0 100 0.25 - 2 99.4 0 100 0 100 Bnd. Pareto 0.25 - 5 99.9 0 100 0 100 α = 0.05 0.25 - 10 100 0 100 0 100 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 42. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Summary of Experimental Results Task Acceptance - RT-Axis2 accepts 42-100% of tasks for a good mix of tasks. - Expo and Pareto runs = 100% acceptance due to high concentration of small tasks. - Can fit more small tasks into a given period of time Real-time Axis2 Unmodified Axis2 Distribution Inter-arrival % Acc. % D. Mis. % D. Met % D. Mis. % D. Met time(sec) 0.25 - 5 41.8 0 100 96.6 3.4 Uniform 0.25 - 10 81.2 0 100 83.6 16.4 Bnd. Expo. 0.25 - 2 62.5 0.1 99.9 42.6 57.4 0.25 - 5 99.3 0 100 0 100 λ = 10−6 0.25 - 10 100 0 100 0 100 Bnd. Expo. 0.25 - 2 100 0 100 0 100 0.25 - 5 100 0 100 0 100 λ = 10−5 0.25 - 10 100 0 100 0 100 0.25 - 2 100 0.3 99.7 0 100 Bnd. Pareto 0.25 - 5 100 0.1 99.9 0 100 α = 0.5 0.25 - 10 100 0 100 0 100 0.25 - 2 99.4 0 100 0 100 Bnd. Pareto 0.25 - 5 99.9 0 100 0 100 α = 0.05 0.25 - 10 100 0 100 0 100 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 43. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Summary of Experimental Results Task Acceptance - RT-Axis2 accepts 42-100% of tasks for a good mix of tasks. - Expo and Pareto runs = 100% acceptance due to high concentration of small tasks. - Can fit more small tasks into a given period of time Real-time Axis2 Unmodified Axis2 Distribution Inter-arrival % Acc. % D. Mis. % D. Met % D. Mis. % D. Met time(sec) 0.25 - 5 41.8 0 100 96.6 3.4 Uniform 0.25 - 10 81.2 0 100 83.6 16.4 Bnd. Expo. 0.25 - 2 62.5 0.1 99.9 42.6 57.4 0.25 - 5 99.3 0 100 0 100 λ = 10−6 0.25 - 10 100 0 100 0 100 Bnd. Expo. 0.25 - 2 100 0 100 0 100 0.25 - 5 100 0 100 0 100 λ = 10−5 0.25 - 10 100 0 100 0 100 0.25 - 2 100 0.3 99.7 0 100 Bnd. Pareto 0.25 - 5 100 0.1 99.9 0 100 α = 0.5 0.25 - 10 100 0 100 0 100 0.25 - 2 99.4 0 100 0 100 Bnd. Pareto 0.25 - 5 99.9 0 100 0 100 α = 0.05 0.25 - 10 100 0 100 0 100 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 44. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Summary of Experimental Results Impact of Inter-arrival rate - Acceptance rate ∝ Inter-arrival time - Smaller inter-arrival times leads to task build-up at the server - Larger inter-arrival times means, on avg. more tasks completed by the next arrival Real-time Axis2 Unmodified Axis2 Distribution Inter-arrival % Acc. % D. Mis. % D. Met % D. Mis. % D. Met time(sec) 0.25 - 5 41.8 0 100 96.6 3.4 Uniform 0.25 - 10 81.2 0 100 83.6 16.4 Bnd. Expo. 0.25 - 2 62.5 0.1 99.9 42.6 57.4 0.25 - 5 99.3 0 100 0 100 λ = 10−6 0.25 - 10 100 0 100 0 100 Bnd. Expo. 0.25 - 2 100 0 100 0 100 0.25 - 5 100 0 100 0 100 λ = 10−5 0.25 - 10 100 0 100 0 100 0.25 - 2 100 0.3 99.7 0 100 Bnd. Pareto 0.25 - 5 100 0.1 99.9 0 100 α = 0.5 0.25 - 10 100 0 100 0 100 0.25 - 2 99.4 0 100 0 100 Bnd. Pareto 0.25 - 5 99.9 0 100 0 100 α = 0.05 0.25 - 10 100 0 100 0 100 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 45. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Summary of Experimental Results Deadline Achievement - RT-Axis2 results in all accepted tasks achieving deadlines, for a good task mix - Due to best effort nature, Unmod Axis2 misses majority of deadlines for the same - For very small tasks Unmod Axis2 performs marginally better i.e. due to overhead in RT-Axis2 Real-time Axis2 Unmodified Axis2 Distribution Inter-arrival % Acc. % D. Mis. % D. Met % D. Mis. % D. Met time(sec) 0.25 - 5 41.8 0 100 96.6 3.4 Uniform 0.25 - 10 81.2 0 100 83.6 16.4 Bnd. Expo. 0.25 - 2 62.5 0.1 99.9 42.6 57.4 0.25 - 5 99.3 0 100 0 100 λ = 10−6 0.25 - 10 100 0 100 0 100 Bnd. Expo. 0.25 - 2 100 0 100 0 100 0.25 - 5 100 0 100 0 100 λ = 10−5 0.25 - 10 100 0 100 0 100 0.25 - 2 100 0.3 99.7 0 100 Bnd. Pareto 0.25 - 5 100 0.1 99.9 0 100 α = 0.5 0.25 - 10 100 0 100 0 100 0.25 - 2 99.4 0 100 0 100 Bnd. Pareto 0.25 - 5 99.9 0 100 0 100 α = 0.05 0.25 - 10 100 0 100 0 100 V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 46. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Execution time comparison 1 - 5000000 (Uniform); 0.25sec - 5sec (Uniform) 1 - 5000000 (Uniform); 0.25sec - 10sec (Uniform) 600000 1.4e+06 Real-tme Axis2 Real-tme Axis2 Unmodified Axis2 Unmodified Axis2 1.2e+06 500000 1e+06 400000 Execution Time (ms) Execution Time (ms) 800000 300000 600000 200000 400000 100000 200000 0 0 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06 Task Size Task Size Timeliness of Execution - RT-Axis2 achieves better exec. times for task mixes with high variety - Unmod. Axis performs badly for the same due to best effort nature - When requests are predominantly small both perform equally - For very small tasks Unmod. Axis2 is better, i.e. no overhead - RT-Axis2 deviations in expo. and pareto runs are intended. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 47. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. Execution time comparison 1 - 5000000 (Bounded Pareto) A - 0.05; 0.25sec - 2sec (Uniform) 1 - 5000000 (Bounded Pareto) A - 0.5; 0.25sec - 2sec (Uniform) 35000 2500 Real-tme Axis2 Real-tme Axis2 Unmodified Axis2 Unmodified Axis2 30000 2000 25000 Execution Time (ms) Execution Time (ms) 1500 20000 15000 1000 10000 500 5000 0 0 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06 0 100000 200000 300000 400000 500000 600000 700000 800000 900000 Task Size Task Size Timeliness of Execution - RT-Axis2 achieves better exec. times for task mixes with high variety - Unmod. Axis performs badly for the same due to best effort nature - When requests are predominantly small both perform equally - For very small tasks Unmod. Axis2 is better, i.e. no overhead - RT-Axis2 deviations in expo. and pareto runs are intended. V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 48. Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util. CPU Utilisation 1 - 5000000 (Uniform); 0.25sec - 5sec (Uniform) 1 - 5000000 (Uniform); 0.25sec - 10sec (Uniform) 100 100 Axis2 Axis2 90 90 80 80 70 70 CPU Utilization % CPU Utilization % 60 60 50 50 40 40 30 30 20 20 10 10 0 0 0 100000 200000 300000 400000 500000 600000 700000 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 Sample # Sample # - RT-Axis2 achieves high utilisation times when tasks are rejected - Utilisation won’t reach 100% as thread scheduling is done - OS manages all scheduling finally V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 49. Intro Solution Impl. Eval. Conclusion What’s Next? 1 Introduction 2 Proposed Solution 3 Implementation 4 Emperical Evaluation 5 Conclusion V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 50. Intro Solution Impl. Eval. Conclusion Conclusion Summary WS middleware lacks support for Real-time Apps For RT-Apps predictability is the key Proposed a model based on RT-scheduling principles Proposed algorithms based on RT-scheduling principles Live implementation using Axis2 Solution enables acheving predictability even in dynamic environments (empirically evaluated) V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 51. Intro Solution Impl. Eval. Conclusion Conclusion Summary WS middleware lacks support for Real-time Apps For RT-Apps predictability is the key Proposed a model based on RT-scheduling principles Proposed algorithms based on RT-scheduling principles Live implementation using Axis2 Solution enables acheving predictability even in dynamic environments (empirically evaluated) * This is just the first step! * Way Ahead...? V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 52. Intro Solution Impl. Eval. Conclusion Acknowledgements * Sun Microsystems - For providing academic licenses for RTSJ V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings
  • 53. Intro Solution Impl. Eval. Conclusion Thank You ! Comments & Questions ? V. Gamini Abhaya et. al. ICSOC 2009 - pages 364-372 in proceedings

×