Achieving Predictability and Service Differentiation in Web Services

Intro Solution Impl. Eval. Conclusion

Achieving Predictability and Service Diﬀerentiation
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


Agenda

1 Introduction

2 Proposed Solution

3 Implementation

4 Emperical Evaluation

5 Conclusion


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


5 Conclusion



Motivation

Research on QoS fails to guarantee predictability in service
execution.



Motivation

execution.
Assumptions are made on achieving QoS levels.



Motivation

execution.
WS architectures and supporting infrastructures lack support
for predictability.
E.g. - SOAP engines and App Servers service requests in a
best eﬀort manner.



Motivation

execution.
for predictability.
Design goals are to increase throughput by concurrent
processing.

No. of requests served parallely ∝ Time taken to service a request



Motivation

execution.
for predictability.
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



Real-time Applications [9]

Characteristics




Characteristics
Real-time computing = Super Fast computing (Instantaneous)




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




Misconceptions

Characteristics

Should not sacriﬁce the deadline of an important task for the sake
of another (even if it has to be rejected)




Misconceptions

Characteristics

Should not sacriﬁce 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 ﬂoor
control systems



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.



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.


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


5 Conclusion




Deﬁnition
Absolute time period the request must be serviced within




Deﬁnition
Absolute time period the request must be serviced within

Communicated to the server using SOAP headers


Admission Control

Challenges
1 No prior information about requests and their arrival
2 Diﬃcult to schedule them to meet deadlines



Admission Control

Challenges

Therefore...
It is impossible to accept all requests and still meet all their
deadlines



Admission Control

Challenges

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-ﬂy admission control mechanism based on real-time
scheduling principles




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 oﬄine proﬁled execution time




Step 2
Ensure new task does not compromise the deadlines of already
accepted tasks a
The eﬀect of the new task must be checked individually, on each
task ﬁnishing thereafter
a
(Based on equations 10,11 & 12 of the model)



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%



Sample Scenario

Task ST ET D
T1 0 5 25

ST - Start Time (ms)
ET - Execution Time (ms)
D - Deadline (ms)



Sample Scenario

Task ST ET D
T1 0 5 25
T2 1 6 19

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)



Sample Scenario

Task ST ET D
T1 0 5 25
T2 1 6 19
T3 3 3 7

D - Deadline (ms)


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)

Loading Factor = 11
(25−3)
0.5 < 1 (Accept request)



Sample Scenario

Task ST ET D
T1 0 5 25
T2 1 6 19
T3 3 3 7
T4 4 4 7

D - Deadline (ms)


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...)

Loading Factor = 14
(25−4)
0.737 < 1 (Accept request)



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

D - Deadline (ms)


Loading Factor = 5
(11−7)
1.25 < 1 (Reject Request)



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

D - Deadline (ms)


Total Proc. Demand up to T6 = 9ms (2 + 7)
Loading Factor = 9
(18−8)
0.9 < 1 (Continue...)

Loading Factor = 13
(20−8)
1.083 < 1 (Reject Request)



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

D - Deadline (ms)


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...)

Loading Factor = 15
(25−9)
0.9375 < (Request Accepted)


Intro Solution Impl. Eval. Conclusion Overview Components Enhancements

What’s Next?

1 Introduction

2 Proposed Solution

3 Implementation
Overview
System Components
Enhancements to Axis2


5 Conclusion



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



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



System Components

Development Platform
Real-time Speciﬁcation 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/



System Components

Development Platform
Real-time Speciﬁcation 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



Enhancements to Apache Axis2


Intro Solution Impl. Eval. Conclusion Eval. Summary Exec time comparison CPU Util.

What’s Next?

1 Introduction

2 Proposed Solution

3 Implementation

Summary of Results
Execution time Comparison
CPU Utilisation

5 Conclusion



Experimental Results

Metrics
- Percent. of tasks accepted by RT-Axis2
- Percent. of deadlines met by RT-Axis2 and Unmod. Axis2



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 Unmodiﬁed 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



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 ﬁt more small tasks into a given period of time

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




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

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




Deadline Achievement
- RT-Axis2 results in all accepted tasks achieving deadlines, for a good task mix
- Due to best eﬀort 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

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



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 eﬀort 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.



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 eﬀort 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.



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 ﬁnally



What’s Next?

1 Introduction

2 Proposed Solution

3 Implementation


5 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)



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 ﬁrst step!
* Way Ahead...?



Acknowledgements

* Sun Microsystems - For providing academic licenses for RTSJ



Thank You !

Comments & Questions ?

Achieving Predictability and Service Differentiation in Web Services

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Achieving Predictability and Service Differentiation in Web Services

Semelhante a Achieving Predictability and Service Differentiation in Web Services (20)

Último

Último (20)

Achieving Predictability and Service Differentiation in Web Services