Towards Achieving Execution Time Predictability in Web Services Middleware

Towards Achieving Execution Time Predictability

in Web Services Middleware

Vidura Gamini Abhaya

Supervised byProf. Zahir Tari and Assoc. Prof. Peter Bertok

Distributed Systems and Networking GroupSchool of Computer Science and IT

RMIT UniversityMelbourne, Australia

15th June 2012

-: Completion Seminar :-

Problem Overview Solutions Conclusion

Presentation Structure

1 The Problem Area

2 Research Overview

3 Solutions

4 Conclusion


The Problem

Evolution of the Internet

Transition from:User-Centric → Application Centric → Fully Automated Web

* Facilitated by the use of Web services.

Example:


The Problem

Web Services Middleware

Container applications services are hosted in. Manages all aspectsof their execution.

Characteristics

Optimised for throughput by design

Requests are accepted unconditionally

Uses thread-pools to execute them in a best-effort manner

Processes multiple requests in-parallel using processor-sharing

* They result in inconsistent execution times


The Problem

10 20 30 40

050

0010

000

2000

030

000

Average Execution Time by No. of Requests Executing in Parallel

Number of Requests

Ave

rage

Exe

cutio

n T

ime

(ms)

Service has a linear execution time complexity.

Started with 2 requests sharing the processor and increased by five upto 47requests sharing the processor.


The Problem

Why is predictability of execution important in web services?

To achieve consistent service execution times.

To make service selections based on guaranteed execution times

Prevent clients from being set-up for failure.

To open up new application areas that require predictability in execution, suchas Industrial control systems, Avionics, Robotics and Medical diagnostic systemsto the use of web services as a communications platform.

Problem Overview Solutions Conclusion Aim and Scope Research Questions Related Work

Research Overview

What is predictability of execution?

Execution of a web service completing within a given deadline in aconsistent and repeatable manner.

Aim

Achieve predictability of service execution in stand-alone andcluster-based web services middleware

Scope of Research

Use real-time scheduling principles.

Achieving Predictability is limited to the execution within the web servicesmiddleware.

We assume no delays are experienced on the network.


Research Questions

1 How can predictability of execution be achieved in stand-aloneweb services middleware?

2 How can predictability of execution be achieved incluster-based web service deployments?

3 How can web services middleware be engineered to havepredictable execution times?

4 How can performance models for such systems be derived andcompared against other techniques?


Related Work

Can be categorised broadly into the following,

Admission control mechanisms used to control execution time in web services[Dyachuk et al., 2007], [Elnikety et al., 2004], [Carlstrom and Rom, 2002], [Erradi and Maheshwari, 2005]

Do not consider any predictability attributes such as a deadline or laxity, in the decisions.

Execution time QoS on stand-alone servers[Sharma et al., 2003], [Ching-Ming Tien, 2005]

Achieves some level of differentiated processing, but do not consider any predictability attributes.

Request dispatching techniques aimed at improving execution time[Pacifici et al. 2005], [Garcıa et al., 2009], [Gmach et al., 2008], [Cao et al., 2010]

Achieves execution times defined in SLAs in a probabilistic manner. Execution times can be inconsistent.

Web services middleware using real-time scheduling[Helander and Sigurdsson, 2005], [Mathes et al., 2009]

Predictability is achieved in closed environments, Task properties are known at design time of the system.

Performance models for systems using deadline based scheduling[Li et al., 2007], [Kargahi and Movaghar, 2006], [Chen and Decreusefond, 1996]

Considers M/M/1 systems which assumes service times to be exponentially distributed. Not a good

representation of web service workloads. Only non-preemptive systems are considered.

Problem Overview Solutions Conclusion Q1 Q2 Q3 Q4

Question 1

How can predictability of execution be achieved in stand-alone webservices middleware?


Real-time Scheduling

Arrival TimeExecution

Deadline

Start Time End TimeWaiting

Time

Laxity

The ability to delay the execution of a task without compromising its deadline.

Laxity = Deadline − Arrival Time − Exec. Time Requirement

Can also be defined as, Laxity = Exec. Time Requirement(Deadline − Arrival Time)


Predictability of Execution in Stand-alone Middleware

Introduction of an execution deadline

Laxity based admission control

Earliest Deadline First (EDF) scheduling

0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

T5Arrival

Time

Start Time End Time

DeadlineExecution



Laxity based admission control - Components of analytical model

Remaining Execution Time

Running Laxity - Laxity of a task at a given time

Processor Demand - Units of processing time required (withina time period)

Loading Factor - Ratio between processor demand andprocessing resources available (within a time period)



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

a2

a1

a3

d3

a4 s4 e4

d4

d2

d1

Reference Point

(Arrival of T4)

C4

Laxity based admission control - Components of Analytical Model

Examples:

Remaining Exec. Time (R),R3 = 3 − 1 = 2 (Remaining Exec. Time of T3)R2 = 6 − 2 = 4

Running Laxity (L),L2 = (d2 − a2) − 2 = 17 (Running Laxity of T2)L1 = (d1 − a1) − 1 = 24



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

a2

a1

a3

d3

a4 s4 e4

d4

d2

d1

Reference Point

(Arrival of T4)

C4

Laxity based admission control - Components of Analytical Model

Examples:

Processor Demand (h),h[a4, d4)

= R3 + C4 = 2 + 4 = 6

h[a4,d1)=

∑3j=1 Rj + C4 = 10 + 4 = 14

Loading Factor (u),

u[a4,d4)=

h[a4, d4)d4−a4

= 611−4

= 0.86

u[a4,d1)=

h[a4, d1)d1−a4

= 1421−4

= 0.82



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

Arrival of a Request

Get accepted requests finishingwithin the lifespanof the new request

CalculateLoading Factorwithin lifespanof new request

Can the new task be

scheduled to meet it's deadline?

Request Rejected

Get accepted requests finishing

after the new request

CalculateLoading Factor

between arrival timeof new req. and

deadline of old req.

Will the new task

compromise deadlines of these requests?

Request Accepted

Yes

NoNo

Yes

Repeated seperately, for each request finishing after the new request



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

At the arrival of T4

Proc. Demand within T4 = 6

Loading Factor within T4 = 0.86 ≤ 1 �




Can the new task be


Request Rejected






Will the new task


Request Accepted

Yes

NoNo

Yes




0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4


Proc. Demand between T4 and deadline of T2 = 10

Loading Factor between T4 and deadline of T2 = 0.62 ≤ 1 �




Can the new task be


Request Rejected






Will the new task


Request Accepted

Yes

NoNo

Yes




0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4


Proc. Demand between T4 and deadline of T1 = 14

Loading Factor between T4 and deadline of T1 = 0.82 ≤ 1 �




Can the new task be


Request Rejected






Will the new task


Request Accepted

Yes

NoNo

Yes




0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

T4




Can the new task be


Request Rejected






Will the new task


Request Accepted

Yes

NoNo

Yes




0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 1617 18 19 20 2122 23 24 25

T1

T2

T3

T4

T4


Proc. Demand within T5 = 6

Loading Factor within T5 = 612−7

= 1.2 > 1 ×




Can the new task be


Request Rejected






Will the new task


Request Accepted

Yes

NoNo

Yes



Stand-alone middleware performance

RT-Axis2 accepts between 18.1% (fastest) and 96.7% (slowest) of the requests.

Unmod. Axis2 RT-Axis2

Inter-arrival times(sec)

% Acc. % D. Met off % Acc. % Acc. % D. Met off % Acc.

1.125 (Low) 100 36.2 96.7 1000.75 62.4 18.3 58.6 1000.3 55.1 9.1 30.7 99.70.175 (High) 28.7 8.8 18.1 96.7



RT−Axis2

Axis2

0 10000 20000 30000 40000 50000 60000 70000

0.25sec − 1sec (Uniform)

Execution Time (ms)

RT−Axis2

Axis2

0 50000 100000 150000 200000

0.1sec − 0.5sec (Uniform)

Execution Time (ms)



RT (0.175s)

A (0.175s)

RT (0.3s)

A (0.3s)

RT (0.625s)

A (0.625s)

RT (1.125s)

A (1.125s)

0 2 4 6 8 10 12

Comparison of Resultant Laxities − Standalone Setup RT−Axis2 (RT) vs Axis2 (A)

Laxity

0

1

2

3

4

5

6

1.125s 0.625s 0.300s 0.175s

Thro

ughput

(Tasks p

er

second)

Mean inter-arrival times (sec)

Comparison of Throughput - Unmod Axis2 vs RT-Axis2

Unmod. Axis2RT-Axis2

RT-Axis2 (excl. rej.)

Unmod. Axis2 RT-Axis2

Mean inter-arrivaltime

Throughput (sec−1) Throughput (sec−1) Throughput (excl.rejected)

1.125s (Low) 0.98 0.91 0.880.625s 0.83 1.62 0.950.300s 0.72 3.40 1.040.175s (High) 0.69 5.64 1.02


Question 2

How can predictability of execution be achieved in cluster-basedweb service deployments?


Predictability in Cluster-based Middleware

Dispatching Algorithms - Objectives

*Ensures deadline requirement of tasks could be met*Distribute requests evenly among executors based on a condition*Avoids executors going into overload conditions

4 algorithms used

RT-RoundRobin

RT-Sequential

RT-ClassBased

RT-LaxityBased


RT-RoundRobin

Details

Requests assignment cyclesthrough all executors in RRfashion

Sched. check is done only onceper request

If sched. check fails on selectedserver → request rejected

Hightlights

POC for how a simple dispatching algorithm could be made real-time ready

Processing overhead is minimum


RT-Sequential

Details

Requests are assigned in asequential manner

Req’s sent to one executor tillsched. check fails, then assignedto the second and so on

Sched. check happens againstmultiple executors till a requestcan be assigned

Highlights

If it’s possible to schedule a job within the cluster, it will be guaranteed


RT-ClassBased

Details

Requests are divided into classesbased on a priority scheme

Mapping of requests to executorsis pre-determined and definedoffline

Sched. check is only consideredwith the assigned executor

Reference implementation usespriorities based on task sizes

Highlights

Results in the reduction of variance of task sizes at each executor

Pre-defined mapping of request sizes to executors could be done usingpre-profiled execution times or execution time history


RT-LaxityBased

Details

Laxity = Ability of delaying arequest whilst still meeting itsdeadline

Higher the laxity the morerequests an executor could service

Sched. check is done only againstthe assigned executor

Highlights

Distribution of requests results in a broad range of laxities at each executor

Keeps track of the last two laxities assigned and prevents them being assignedfor the same executor consecutively


RT-RoundRobin vs Round-Robin

0

2000

4000

6000

8000

10000

12000

0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06

Exe

cutio

n T

ime

(ms)

Task Size

Task Size distribution between 3 Executors (1 - 5000000 (Uniform); 0.1sec - 0.5sec (Uniform) roundrobin 3 exec)

Executor 1Executor 2Executor 3

RT-RR accepts between 20.5% (2 Exec. - fastest) and 99.9% (4 Exec. -slowest) of the requests.


RT-ClassBased vs Class Based

0

10

20

30

40

50

60

70

80

90

0 50 100 150 200 250 300 350 400

CP

U U

tiliz

atio

n %

Sample #

CPU utilisation at each Executor - (1 - 5000000 (Uniform); 0.25sec - 1sec (Uniform) classbased 3 exec)

Executor 1Executor 2Executor 3

RT-CB accepts between 28.6% (2 Exec. - fastest) and 100% (4 Exec. - slowest) of the requests.


RT-Sequential and RT-Laxity

Highest acceptance rate for any algorithm for 2 executors with highest arrivalrate is 38.5% for RT-LaxityBased

RT-Sequential records the lowest percentage of deadlines met out of allalgorithms. However, given its best acceptance rates out of all, the averagenumber of requests meeting its deadline is second to only RT-LaxityBased.


Question 3

How can web services middleware be engineered to havepredictable execution times?


Infrastructure

Dev Platform and OS

Solaris 10 08/05 is used as the Real-time OS

Sun Real-time Java Specification is used as the Dev Platform


Introduction of the Deadline

SOAP Envelope

SOAP Body

Payload

SOAP Header

Header

Header

<?xml version='1.0' encoding='UTF-8'?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header>

<ns1:RealTimeParams xmlns:ns1="http://endpoint.testservice">

<ns1:Deadline>70</ns1:Deadline>

<ns1:Period>0</ns1:Period>

<ns1:clientid>Client1</ns1:clientid>

<ns1:ExecTime>28</ns1:ExecTime>

</ns1:RealTimeParams>

</soapenv:Header>

<soapenv:Body>

<ns1:primeCount xmlns:ns1="http://endpoint.testservice">

<ns1:primeLimt>102155</ns1:primeLimt>

</ns1:primeCount>

</soapenv:Body>

</soapenv:Envelope>

An example of how the processing deadline could be conveyed tothe middleware - using SOAP headers


Priority Model

Three priority levels are introduced (used by the Real-time Scheduler)

High - Cannot be interrupted by GC - Used on a thread to allow execution

Mid - Can be interrupted by the GC - Used on a thread to prevent execution

Low - Can be interrupted by the GC, Highest priority level available on StandardJava - Used for meta data requests i.e. WSDL


Enhancements made to Axis2

Details

Thread-pools have been replaced with RT-Threadpools

A Real-time scheduler has been introduced

Multiple execution lanes are used


Enhancements made to Synapse

Details

Enhanced version of Synapse used for dispatching

Thread-pools have been replaced with RT-Thread poolsA Real-time scheduler has been introducedMultiple execution lanes are used

RT-Axis2 instances used as Executors

Request processing happens at Dispatcher, Service Invocation at Executors


Minimising Priority Inversions

Can be caused by, I/O activities such as reading/writing to files and sockets.

To prevent priority inversions,

Avoid outputs resulting in on-screen messages or log file writes

Use in-memory logging and delayed writes

Use offline debugging techniques/toolse.g. Oracle Thread Scheduling Visualizer (TSV)


Question 4

How can performance models for such systems be derived andcompared against other techniques?


Performance model

Why model the system?

To derive different performance attributes not based on deadlines

To better compare the performance of techniques used, to others that do notshare the same performance attributes

To investigate the behaviour of the system analytically, without having to turnto implementations


System characteristics

Uses EDF scheduling

Arbitrary number of priority classes

Executions are preemptive-resume (work-conserving)

Waiting time considered to be the primary performance indicator

Requests have arbitrary service times

Requests arrive according to a Poisson process

* The system is modelled as a preemptive-resume M/G/1/./EDF queue.


System parameters

N number of priority classes

Each class assigned with a constant deadline offset. i.e a task from stream i onits arrival at the system at time t will have a deadline offset of t + di

Priority of a stream is decided by the associated deadline. i.e. i is consideredhigher priority if i < j ⇒ di ≤ dj

Difference between deadline offsets denoted by Dj,i = dj − di .

Queueing discipline among priority classes is EDF and within the class is FCFS.

Each priority class has a different arrival rate denoted by λi

The resultant load for each priority class is denoted by ρi

* The work of Chen K. and Decreusefond L., that approximates waiting time for a

non-preemptive EDF system. Our model, extend their work to a preemptive-resume

system.


Performance Model

Wi = W0i+

∑ik=1 ρkWk +

∑Nk=i+1 ρk max(0,Wk −Dk,i ) +

∑i−1k=1 ρk min(Wi ,Di,k)

Parameters

In the point of view of a newly arriving request (tagged request)

- Mean waiting time experienced by stream i requests

- Mean residual service time as experienced by stream i requests

- Requests from higher priority classes found in the system by a newly arrived task and are served prior tothe newly arrived.

- Requests from lower priority classes found in the system by a newly arrived task and are served prior to thenewly arrived.

- Requests from higher priority classes arriving at the system after a given task and being serviced prior to it.

Newly Arrived

Request

( d - d )2 1

t2 t + d2 2J

t1 t1+ d1I


Performance Model

Wi = W0i+

∑ik=1 ρkWk +

∑Nk=i+1 ρk max(0,Wk −Dk,i ) +

∑i−1k=1 ρk min(Wi ,Di,k)

Parameters

In the point of view of a newly arriving request (tagged request)

- Mean waiting time experienced by stream i requests

- Mean residual service time as experienced by stream i requests

- Requests from higher priority classes found in the system by a newly arrived task and are served prior tothe newly arrived.

- Requests from lower priority classes found in the system by a newly arrived task and are served prior to thenewly arrived.

- Requests from higher priority classes arriving at the system after a given task and being serviced prior to it.

t1 t1+ d1

t2 t + d2 2

( d - d )2 1

J

I


Mean residual service time

For a preemptive M/G/1 queue (not using EDF),

Ci = Xi +∑i−1

j=1(λjCiXj)

Parameters

- Ci - Mean time required to complete service for a stream i request, includingthe time it is preempted

- Xi - Mean of the service time distribution for stream i requests



Ci

s

Ci

si

Ci = Xi +∑i−1

j=1 (ρj min(Di,j ,Ci ))

Let j∗ = subscript j = 1, 2, ..i − 1 such that Di,j ≤ Ci

Let j′

= subscript j = 1, 2, ..i − 1 such that Di,j > Ci

Ci = Xi +∑

j∗(ρj∗Di,j∗) +∑

j′ (ρ

j′Ci )

Ci =Xi+

∑j∗ (ρj∗Di,j∗ )

(1−∑

j′ ρ

j′ )



Let Pi be the probably of a request from stream i being in service at an arrival. Pi

could be defined as:

Pi = λiCi

Mean residual service time of a system can be defined as the the sum of allprobabilities of a job of a given class is in service, times the mean residual service time

for the given class [Kleinrock, 1976]. Therefore, we could define W0i,

W0i=

∑ik=1

(

PkRk

)

Replacing Pk we get,

W0i=

∑ik=1 Rk

(

ρi+∑

j∗ (ρj′Di,j∗ )λi

(1−∑

j′ ρ

j′ )

)

where Ri =Xi

2

2Xifor an M/G/1 system. (Xi

2is the second moment of the service time distribution for

class i requests.


Evaluation - Analytical results with uniformly distributed service times

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Analytical Waiting Times - Uniform, 2 Priorities

Preemptive P1Preemptive P2

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3Preemptive P4

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3Preemptive P4Preemptive P5


Evaluation - Analytical results with exponentially distributed service times

0

5000

10000

15000

20000

25000

30000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Analytical Waiting Times - Exponential, 2 Priorities

Preemptive P1Preemptive P2

0

5000

10000

15000

20000

25000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3

0

5000

10000

15000

20000

25000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3Preemptive P4

0

5000

10000

15000

20000

25000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load


Preemptive P1Preemptive P2Preemptive P3Preemptive P4Preemptive P5


Evaluation - Analytical results compared with simple M/G/1 systems

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Priority Classes

Comparison of Analytical Waiting Times - Uniform, 4 Priorities - P1

Pre. M/G/1/./EDF P1Non-Pre. M/G/1/./EDF P1

Pre. M/G/1 P1Non-Pre. M/G/1 P1

0

1000

2000

3000

4000

5000

6000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Priority Classes




0

1000

2000

3000

4000

5000

6000

7000

8000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Priority Classes




0

5000

10000

15000

20000

25000

30000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Priority Classes





Evaluation - Analytical vs. Simulation results

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Anlytical and Simulation Waiting Times - Uniform, 2 Priorities

Analytical P1Analytical P2

Simulation P1Simulation P2

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Anlytical and Simulation Waiting Times - Uniform, 3 Priorities

Analytical P1Analytical P2Analytical P3

Simulation P1Simulation P2Simulation P3

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Analytical vs Simulation Waiting Times - Uniform, 4 Priorities

Analytical P1Analytical P2Analytical P3Analytical P4

Simulation P1Simulation P2Simulation P3Simulation P4

0

2000

4000

6000

8000

10000

12000

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Wai

ting

Tim

es (

ms)

Overall Load

Comparison of Analytical vs Simulation Waiting Times - Uniform, 5 Priorities

Analytical P1Analytical P2Analytical P3Analytical P4Analytical P5

Simulation P1Simulation P2Simulation P3Simulation P4Simulation P5

Problem Overview Solutions Conclusion Contributions Outcomes Future Work Acknowledgements

Summary of Contributions

1 How can predictability of execution be achieved in stand-alone web servicesmiddleware?Mathematical model and algorithm for run-time laxity based admission control.Introduction of deadline based scheduling.

2 How can predictability of execution be achieved in cluster-based web servicedeployments?Four request dispatching algorithms based on the laxity property.

3 How can web services middleware be engineered to have predictable executiontimes?Software engineering techniques, algorithms, designs and tools for incorporatingpredictability into web services middleware.

4 How can performance models for such systems be derived and compared againstother techniques?Queueing theory based performance model for a preemptive work conservingM/G/1/./EDF queue.


Thesis Outcomes

V. Gamini Abhaya, Z. Tari, and P. Bertok. Achieving Predictability and Service Differentiation in WebServices. In ICSOC-ServiceWave 09: Proceedings of the 7th International Conference on Service-OrientedComputing, Stockholm, Sweden, November 24-27, 2009, pages 364-372. Springer, 2009.

V. Gamini Abhaya, Z. Tari, and P. Bertok. Using Real-Time Scheduling Principles in Web Service Clustersto Achieve Predictability of Service Execution. In Service Oriented Computing: 8th InternationalConference, ICSOC 2010, San Francisco, CA, USA, December 7-10, 2010. Proceedings, pages 197-212.Springer, 2010.

V. Gamini Abhaya, Z. Tari, and P. Bertok. Building web services middleware with predictable serviceexecution. In Web Information Systems Engineering - WISE 2010: 11th International Conference, HongKong, China, December 12-14, 2010, Proceedings, pages 23-37. Springer-Verlag New York Inc.(* Won best student paper award)

V. Gamini Abhaya, Z. Tari, and P. Bertok. Building web services middleware with predictable executiontimes. World Wide Web Journal, pages 1-60, 28 Mar 2012.

V. Gamini Abhaya, Z. Tari, P. Bertok. P. Zeephongsekul Waiting time analysis for multi-classpreemptive-resume M/G/1/./EDF queues. Journal of Parallel and Distributed Computing. (In Work)


Future Work

Predictability in the network layer

Extending predictability across application boundaries

Reducing request rejections through selective re-transmissiontechniques

Improvements to the preemptive M/G/1/./EDF model

Performance models for preemptive G/G/1/./EDF queue


Acknowledgements

Prof. Zahir Tari and Assoc. Prof. Peter Bertok

Prof. Panlop Zeephongsekul

Miss. Dora Drakopoulos and Mrs. Beti Stojkovski

School of Computer Science and IT and its admin staff

Mr. Don Gingrich

DSN staff and students

My Family


Thank You !

&

Questions or Comments ?

Towards Achieving Execution Time Predictability in Web Services Middleware

Technology

execution time predictability

execution time qos

execution deadlinelaxity

execution timepacici

inconsistent execution

average execution time

use of web services

deadline arrival time