WARegistry performance

Hi,

We've tested our seaside (2.8) application with ab [1] and found that
the performance decreases with repeated runs of the benchmark.
Ab creates a new session for every request, so we've looked into the
session handling code and found that WARegistry spends O(n)
time with housekeeping for every new session, where n is the number of
registered sessions. This means that creating n sessions rapidly
takes O(n^2) time.

SeasideRegistry-ul.3.mcz [2] contains an alternative approach which
needs O(n) time for n new sessions, amortized O(1) time for every
session.
We use a LinkedDictionary, which is a combination of a dictionary and
a linked list. In the list handlers are sorted by expiration time.
Every time
a new session is created we unregister all the expired sessions, which
can be found at the beginning of the list. When a session is accessed
then we move it to the end of the list.

To try it out you need to load HashTable from [3] first.

counter_benchmark.pdf [4] contains some benchmarks created with
autobench [5]. We used Seaside-2.8-578 one-click image. Set the
backlog
size to 100 in TcpListener. Some graphs can be found at [6].

What do you think?

Cheers, Levente and Balázs

[1] Apache HTTP server benchmarking tool:
http://httpd.apache.org/docs/2.2/programs/ab.html
[2] http://leves.web.elte.hu/linkeddictionary/SeasideRegistry-ul.3.mcz
[3] HashTable ss repo: http://www.squeaksource.com/ht.html
[4] http://leves.web.elte.hu/linkeddictionary/counter_benchmark.pdf
[5] http://www.xenoclast.org/autobench/
[6] http://leves.web.elte.hu/linkeddictionary/
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Sat, Dec 13, 2008 at 11:35 PM, Balázs Kósi <[hidden email]> wrote:
> What do you think?

Well, I like the look of the benchmarks anyway. :)

In Seaside 2.9, WARegistry now keeps things in a WACache instance.
WACache is designed to be pluggable in terms of expiry, reaping, etc.
but hasn't been optimized at all (I'm not even certain the concurrency
is right yet :) ). If you're at all interested in seeing how your
changes could be implemented in 2.9 as well, I'm sure that would be
appreciated.

Julian
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> We've tested our seaside (2.8) application with ab [1] and found that
> the performance decreases with repeated runs of the benchmark.
> Ab creates a new session for every request, so we've looked into the
> session handling code and found that WARegistry spends O(n)
> time with housekeeping for every new session, where n is the number of
> registered sessions. This means that creating n sessions rapidly
> takes O(n^2) time.

Is the creation of dozens of new session a realistic benchmark for a
typical Seaside application? Do you have a practical use-case where
this actually matters?

I don't think so. The creation of new sessions is a "relatively" rare
event compared to all the requests coming in. Furthermore, the
registry-bookkeeping causing an iteration over all active session only
happens every 10th time, so normally users should not notice this
anyway.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/12/13, Balázs Kósi <[hidden email]>:
> Hi,
>
> We've tested our seaside (2.8) application with ab [1] and found that
> the performance decreases with repeated runs of the benchmark.
> Ab creates a new session for every request, so we've looked into the
> session handling code and found that WARegistry spends O(n)
> time with housekeeping for every new session, where n is the number of
> registered sessions. This means that creating n sessions rapidly
> takes O(n^2) time.

The problem is that reaping the expired session requires iterating
over all the sessions, right?

> SeasideRegistry-ul.3.mcz [2] contains an alternative approach which
> needs O(n) time for n new sessions, amortized O(1) time for every
> session.
> We use a LinkedDictionary, which is a combination of a dictionary and
> a linked list. In the list handlers are sorted by expiration time.
> Every time
> a new session is created we unregister all the expired sessions, which
> can be found at the beginning of the list. When a session is accessed
> then we move it to the end of the list.

And you store the node in the dictionary so you don't have to search for it.

> To try it out you need to load HashTable from [3] first.

Is there any special reason why you don't use dictionary?

> counter_benchmark.pdf [4] contains some benchmarks created with
> autobench [5]. We used Seaside-2.8-578 one-click image. Set the
> backlog
> size to 100 in TcpListener. Some graphs can be found at [6].
>
> What do you think?

It only works when all the sessions have the same lifetime.

Cheers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside