Aspect-oriented Application-level Schedulingfor J2EE ServersKenichi Kourai, Hideaki Hibino,and Shigeru Chiba

Tokyo Institute of Technology

Is AOP useful for anything except logging?

The visitor pattern

And what else?

Our assumption

AOP is useful for performance tuning

Fixing unexpected performance problemsat the last stage of software development

Without major architectural changes

Kasendas: our case study

A river monitoring system Collects and reports water levels of major rivers in Ja

pan Developed by an outside corporation independently

Using JBoss, Tomcat, Struts, and Seasar2 12,000 lines of code 8.8 man-month

chartgeneration

datacollection

datagenerator

datagenerator

DB

Kasendas

water levels

water-levelupdate (emulator)

The map of Japan

Current water levels in Tokyo

Chart of recent changes of water levels

A performance problemin the first release No quality of service (QoS)

Kasendas failed periodic data collection under heavy workload

The data collection must finish within 15 seconds Triggered every 15 seconds

Chart generation interferes with the data collection A heavy-weight task

time15 seconds

deadline misscollection time

many requests

Kasendas

Aspect-orientedapplication-level scheduling QoSWeaver

Enables scheduling at the application level

A thread periodically calls a scheduler's method

The method causes the thread to yield its execution voluntarily

according to a scheduling policy

Separates scheduling code into an aspect

schedulerobject

thread A

thread B

aspect

Development cost

Less than 1 man-month by our student To find the cause of instability (1 week) To develop a scheduling policy by trial and error

(less than 2 weeks) To test and modify the policy (1 week)

For comparison 0.9 man-month to modify potential performance

improvement No bottleneck analysis No guarantee

Technology

The inside of QoSWeaver

Preemptive schedulingat the application level Long-running threads should be preempted by

higher-priority threads Scheduling code should be inserted everywhere in

applications Inserting scheduling code at several points is not enough

Non-preemptive Preemptive

t t

chart generation chart generation

data collection data collection

Profile-based pointcut generator

Automatically generates pointcuts for inserting scheduling code Manually defining pointcuts is difficult

There are many candidates Scheduling code should be called at regular intervals

Based on execution profile Information on all join points (method calls)

Time stamps, caller's methods, and callee's methods Pointcuts are generated from a sequence of these join points

Algorithm of pointcut generation

Overview The algorithm divides execution profile into time slots

by a given interval It generates pointcuts to select only one join point for

each time slot (if possible) Developers generate pointcuts for various parameters They choose the best set of pointcuts experimentally

time slot(10 ms)

time

join point

Algorithm by example

Pointcut candidates circle, diamond, triangle, hexagon, square, and star

1st iteration

2nd iteration

3rd iteration

Initial state

See the paper for the detailed algorithm

Applied scheduling policy

Proportional-share scheduling For two groups

A high-importance task: periodic data collection A low-importance task: chart generation

Policy To keep the ratio of the number of threads

1:1 was the best in our environment The number of low-importance threads is

limited to 1 while a high-importance thread is running

highlow

Developed aspect (pointcuts)<pointcut-decl> <name> lowImportance </name> <pointcut> execution(void PlaceChartCreatePseudActionImpl.execute(..)) </pointcut></pointcut-decl>

<pointcut-decl> <name> highImportance </name> <pointcut> execution(void CollectorImpl.doObtain()) </pointcut></pointcut-decl>

<pointcut-decl> <name> controlPoint </name> <pointcut> (withincode(Range CategoryPlot.getDataRange(ValueAxis)) ANDAND call(Range Range.combine(Range, Range))) OROR : </pointcut></pointcut-decl>

generated by thepointcut generator(17 pairs)

method executionfor chart generation

method execution forperiodic data collection

written in GluonJ [Chiba et al.'05]

Developed aspect (advice)

Advice calls methods of the PSScheduler class A support class

Creates a scheduler object Implements a real scheduli

ng policy 150 lines of code

<behavior> <pointcut> lowImportance </pointcut> <around> PSScheduler.startLowImportance(); $_ = proceed($$); PSScheduler.endLowImportance(); </around></behavior>

<behavior> <pointcut> highImportance </pointcut> <around> PSScheduler.startHighImportance(); $_ = proceed($$); PSScheduler.endHighImportance(); </around></behavior>

<behavior> <pointcut> controlPoint </pointcut> <before> PSScheduler.yield(); </before></behavior>

Developed scheduler

Methods startHighImportance()

Sets yield flags to all but one low-importance thread

yield() Calls wait() if the yield flag is set

endHighImportance() Resets yield flags of all

low-importance threads Calls notify() to all

suspended threads

schedulerobject

high-importancethread

low-importancethreads

1. startHighImportance

2. yield

4. endHighImportance

6. return

3. suspend

5. wakeup

Our experience:aspects Aspects allowed us to change a scheduling policy wit

hout modifying Kasendas Initial policy

Low-importance threads call sleep() except within the library Ineffective because the library consumed CPU time

Second policy Low-importance threads call sleep() anywhere

Insufficient because many threads woke up at the same time

Final policy Low-importance threads call wait()

Effective because the thread execution is controlled properly

Our experience:pointcut generator The pointcut generator enabled us to select appro

priate pairs of pointcuts It selected 17 pairs out of 803 candidates

The total number of join points was 248,661

The pointcut generator could re-generate pointcuts when Kasendas was modified

Kasendas was released several times Appropriate pointcuts changed

We did not need to modify the pointcut definition in our aspect

Experiments

We measured execution performance For comparison

Original Kasendas Kasendas tuned with admission control

Limits the number of running threads Only for new requests

Already running threads are notsuspended halfway

Apache JMeter to generate heavy workload Concurrently sent 40 requests to the low-importance task

Servers: Sun Fire V60x, Linux 2.6.8, Sun JVM 1.4.2, Jboss 4.0.2Client: Sun Fire B100x, Solaris 9, Sun JVM 1.4.2

requests

Kasendas

Time for collecting water levels

The data collection must finish within 15 seconds Triggered every 15 seconds

Original 29.5 seconds

QoSWeaver 5.3 seconds

Admission control 10.1 seconds Unstable

Number of runninglow-importance threads The scheduling policies should reduce the number

to 1 as soon as possible when a high-importance thread starts running

QoSWeaver 1.9 seconds

Admission control Often fail to reduce

the number to 1 12.0 seconds

Performance impacts againstthe low-importance task Overhead by calling a scheduler

No high-importance thread QoSWeaver

6.6%

Performance degradation Suspending low-importance threads

during periodic data collection QoSWeaver

19%

Limitation

QoSWeaver may cause deadlocks For applications using

synchronization

Web applications would not ofteninclude synchronization code

Kasendas did not use threadsynchronization

Using wait(timeout) could prevent deadlocks instead of wait()

synchronized (o) {

}1. A thread issuspended

2. Other threadsare blocked

cannotwake up!

Related work

Re-QoS [Tesanovic et al. '05] Adapts applications to the real-time systems

By admission control

Bossa [Aberg et al. '03] Enables developers to change the OS scheduler

By using DSL and AOP

ALPS [Newhouse et al. '06] Controls UNIX processes by a scheduler process

Not applicable to applications in Java

Conclusion

AOP is useful for performance tuning QoSWeaver

AOP makes application-level scheduling realistic The profile-based pointcut generator automatically generates p

ointcuts

Kasendas Our scheduling policy could fix the performance problem

at the last stage of the development Our experiences show that aspects and the pointcut generator

were helpful

Distribution of selected join points

Average profiled intervals

Average real intervals

Differences by parameters

Difference ofscheduling overhead