directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ole ersoy" <ole.er...@gmail.com>
Subject Re: Benchmarks feedback
Date Tue, 27 Mar 2007 01:46:43 GMT
Cool - Sounds awesome.

One thing that comes to mind is having the capability
to test individual call sequences / segments during the request / result
cycle
so that we know where bottlenecks are.

I remember reading about it while browsing through the Eclipse TPTP
documentation a while back, which also showed the bottlenecks in a sequence
diagram I think.

In this case I would think that the client is the bottle neck, since
it sounds like the server has plenty of  extra juice still.

Cheers,
- Ole




On 3/26/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> ole ersoy a écrit :
>
> > I wonder if disk access could be the bottle neck?
>
> I have done some more test, after I realized that I didn't correctly set
> the cache siez, nor th ememory dedicated to the JVM : Tha cache was
> containing only 100 entries, so each read was done using the File System
> (but with 20 Gb ram, a read is done entirely in memory).
>
> I get better results : up to 3000 req/s on the random searches, which is
> twice better than what I observed before. Cache helps !
>
> Now, I get some run queues (vmstat 1):
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
> r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
> 10  0      0 13379076 361024 5123816    0    0     0    44 14314 32902
> 15  4 80  0
> 6  0      0 13378356 361024 5123816    0    0     0     0 14487 40173
> 20  4 75  0
> 12  0      0 13378404 361024 5123816    0    0     0     0 13614 39101
> 15  4 81  0
> 18  0      0 13377824 361024 5123816    0    0     0     0 14611 41310
> 16  4 80  0
> 3  0      0 13377848 361024 5123816    0    0     0     0 13470 46931
> 18  3 78  0
> 0  0      0 13376148 361024 5123816    0    0     0     0 6836 24492
> 15  2 83  0
> 7  0      0 13391344 361024 5123752    0    0     0    72 2081 5066 14
> 4 82  0
> 11  0      0 13383120 361024 5123784    0    0     0     0 17499 61286
> 18  3 79  0
>
> The clients are sometime burning some heavy cpu cycles :
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 24687 elecharn  20   0  798m 294m  13m S   93  1.5  68:50.31 java
> 3835 elecharn  17   0 1102m  82m 1492 S   57  0.4   0:01.71 java
> 3831 elecharn  23   0 1102m  82m 1492 S   54  0.4   0:01.64 java
> 3833 elecharn  17   0 1103m  82m 1492 S   52  0.4   0:01.58 java
> 3837 elecharn  17   0 1103m  81m 1492 S   47  0.4   0:01.42 java
>
> I guess that I need to run more injectors with less threads
>
> >
> > Would be interesting to see what happens if we get
> > a memory resident partition and run the same test against that.
>
> Well, with a correctly sized cache, this is what we obtain : 3000 req/s,
> at best (average around 2000 req/s)
>
> >
> > Would be really sweet to get the whole box humming.  Thanks Matt and
> > Emmanuel!
> > It's great to be aware of this type of stuff.  I have a couple of 20 cpu
> > servers in my closet,
> > but  I have not had a chance to dust them off yet (Yeah, umhummm, sure).
>
> I also have a PDP 11 somwhere, but it's currently running since last
> year computing 45! ...
>
> Emmanuel
>
>

Mime
View raw message