Implementation Of The Dual Leaky Bucket Algorithm On Jigsaw Web Server

1
Implementation Of The Dual Leaky Bucket Algorithm
On Jigsaw Web Server
Supervisor Jakob Carlstrom

• Submitting Maxim Terletsky
• Hagay Unterman

2
Introduction

• High load at a web server often results in
  heavily delayed responses to user requests,
  making users abandon the web server.
• One solution to this problem is to limit the
  number of clients that are served concurrently.
• However, this is a bad solution if the
  client/server interaction is session-oriented
  (such as e-commerce).

3
Introduction ( Continue)

• A good solution would be, rejecting a fraction of
  arriving session requests in overload situations.
  

4
Goal

• The goal of this project is to design and
  implement a mechanism for admission control and
  traffic shaping of web session traffic.
• The suggested mechanism is a "dual leaky bucket".

5
Goal ( Continue)

• Another goal is to write
  a simple admission control
  algorithm for comparison. ( We
  decided to go for algorithm which simply limits
  the number of possible opened sessions)

6
Goal ( Continue)

• And the last, but not least is to implement the
  second leaky bucket on client side, not server.
  (Explanation later)

7
Environment

• The web server we deal with is the Jigsaw web
  server version 2.0.5.
• The implementation will be in Java. ( We have the
  sources of Jigsaw written in Java)

8
What The Leaky Bucket Is All About?

• The "leaky bucket" algorithm
  is a key to defining the meaning
  of conformance. The leaky
  bucket analogy refers to
  a bucket with a hole in the
  bottom that causes it to "leak" at a certain rate
  corresponding to a traffic cell rate parameter.
  The "depth" of the bucket corresponds to a
  tolerance parameter.

9
Second Bucket

• While the first bucket simply holds leaking time
  versus sessions, second bucket keeps the rate of
  incoming sessions lower than some MAXIMUM value.
• It doesnt deny any session.
• Instead, it stores it in queue and open session
  after certain amount of time has passed. (So the
  rate will be less than MAXIMUM).

10
Supervisors idea

• Implementation of second bucket on the client
  side.
• Server counts the amount of time that client
  should wait, and then send it to client. After
  client waits this amount of time he enters again
  and gets session immediately.

11
Example

• Session requests on time scale

Time
Granting sessions according to algorithm
Time
12
What Do We Get From It?

• We save storing place and time
  on the servers side,
  because we dont store requests
  anywhere. (Storing queue is virtually implemented
  on clients side)

13
Problems We Encountered With..

• Learn how to write code in Java.
• Understand the most complicated, huge code of the
  Jigsaw. (With no real Class Diagram or Sequence
  Diagram ready).
• Implementation of the Leaky Bucket algorithm in
  Jigsaw web server.
• Implementation of the second leaky bucket at the
  client side.

14
More Specific Problems And Decisions

• Implementation of the second leaky bucket at the
  client side with the help of HTML and
  JavaScript.
• Sending HTML page to the client on the lowest
  level of Jigsaw hierarchy simulation of
  classes, adding pseudo constructors and changing
  privileges of different methods and variables in
  existing Jigsaw code.

15
More Specific Problems And Decisions ( Continue)

• How to identify the client which got stuck in the
  second bucket, waited specific amount of time and
  got back? ( We have to identify him somehow so he
  will get session and not wait again)
• Two possible solutions by cookie or by ip of
  the client.
• We choose the ip solution.

16
How To Evaluate

• Using the existing tool Webstone, we will
  evaluate performance of Jigsaw with different
  admittance control algorithms Simple one and
  dual leaky bucket. (When second bucket
  implemented on clients side).

17
Results

• The results will be taken from some benchmarks
  exams
• With a simple algorithm.
• With a Dual Leaky Bucket algorithm.

18
Thanks to..

• Special thanks to all the Comnet Lab crew
• YoramYoram, Vlad and Vitaly.
• Our supervisor
• Jakob Carlstrom

19
The End!