directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject [Benchmark] Some more informations
Date Thu, 29 Mar 2007 13:20:11 GMT
Hi,

I have been doing some tests on my computer (Mac OSX, intel core duo) with
some traces to see where in the server we migh have some bottleneck.

The result I got was around 1500 req/s, with the very same injector I used
on Matt's server.

I have added a counter in the SearchHandler :
- added a static counter and a static cumulative counter
- get the nanoTime/1000 at the begining of the method,
- get the nanoTime/1000 just before returning the result
- before returning, the current delta (start - end) is added to the
cumulative counter and the counter is incremented
- when the counter reach 1000 rounds, print the cummulative counter divided
by 1000, and reset it.

This is to measure the time inside the server to fetch the entry, excluding
decoding/encoding the request/response, and excluding Mina

The results are pretty impressive :
Search cost : 8756
Search cost : 3409
Search cost : 848
Search cost : 342
Search cost : 189
Search cost : 133
Search cost : 113
Search cost : 137
Search cost : 82
Search cost : 75
Search cost : 70
Search cost : 62
Search cost : 57
...
Search cost : 23
Search cost : 21
Search cost : 20
Search cost : 19
Search cost : 19
Search cost : 18
Search cost : 18
Search cost : 18
...
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 3
Search cost : 3
Search cost : 4
Search cost : 3
Search cost : 3
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 4
Search cost : 3
Search cost : 3
Search cost : 3
... (and the delta now increase because the number of threads is too big
coimpared to the number of processors)

All the numbers are in micro seconds, which means we potentially can handle
as much as 300 000 search/s !

Know, I'm going to set the same counters before and after the codec, to see
how much time it takes to process the PDU in and out, then it will be MINA.

Interesting results, anyway !

(FYI, the server cache has been boosted to avoid any read/write on disk, so
it's just plain CPU)

Emmanuel.

PS: I did this test just to check if we could have a Synchronization point,
and in this case, what could have been its cost. So far, we can consider
that with a 3 microseconds duration for the search, even if synchronized,
this is acceptable...
-- 
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message