jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ChadDavis <chadmichaelda...@gmail.com>
Subject Re: DavEx Remoting Performance
Date Tue, 21 Jun 2011 17:48:49 GMT
Hi John

Have you tried experimenting with the caching parameters as outlined here:

http://wiki.apache.org/jackrabbit/Performance

I haven't tried them yet because I thought, as it seems you did, that
addressing the two connection limit seemed to be of higher priority.

Chad


On Tue, Jun 21, 2011 at 10:12 AM, John Tranier <tranier@gmail.com> wrote:
> Hi,
>
> I'm joining this thread since we are currently facing performance issues
> with our webapp using Jackrabbit through a DavEx remoting set up.
> We do not know yet if the very poor performance are caused by the DavEx
> client itself or a bad usage of it by our application.
>
> We've conducted few preliminary tests using jMeter on 2 scenarios :
> Sc-read: users are reading children nodes under the root of their home node
> Sc-write: users are creating a child node under the root of their home node
>
> All the experiments have been done with a set of 200 users ; what changes
> between runs are the number of concurrent users.
> The average times collected are not significant by themselves since we
> perform our experiment over a development setup, but still it allows to
> compare results.
>
> Experiment A (davex + webapp jackrabbit + postgres) :
> Sc-read - 10 concurrent users : 0,5s
> Sc-read - 40 concurrent users : 2s
> Sc-read - 80 concurrent users : 3,4s
>
> Sc-write - 10 concurrent users : 3,7s
> Sc-write - 40 concurrent users : 8,5s
> Sc-write - 80 concurrent users : 17,2s
>
> Experiment B (embedded Jackrabbit + derby) :
> Sc-write - 10 concurrent users : 1,4s
> Sc-write - 40 concurrent users : 1,5s
> Sc-write - 80 concurrent users : 2,6s
>
> We have noticed that without providing the workspace name to the login
> method, 2 HttpClient are created per session, and only one is destroyed.
>
> Experiment C (davex + webapp jackrabbit + postgres / without providing the
> default workspace name) :
> Sc-write - 10 concurrent users :3,8s
> Sc-write - 40 concurrent users : 10,5s
> Sc-write - 70 concurrent users : 40,2s
> Sc-write - 80 concurrent users : the run is interrupted by an overload of
> many threads running changePolling method
>
> We also thought that the 2 TCP connections was a strong limitation since
> we've seen HttpClient waiting for long before getting a connection.
> We have hooked the configuration to allow a pool of 200 connections ; we do
> not see anymore HttpClient waiting for connection, but surprisingly the
> final response time are worse.
>
> We are very interested in any feedback about the DavEx setup and
> performance.
> Do you think that several embedded repositories within a cluster is a better
> setup than DavEx regarding scalability ?
>
> Cheers,
> John
>
>
>
> 2011/6/16 ChadDavis <chadmichaeldavis@gmail.com>
>
>> I'm doing stress testing on a DavEx remoting set up.  We're seeing a
>> bottleneck between our app ( the JCR client in a davex remoting set up )
>> and
>> the repository server.  When we increase the number of concurrent users
>> hitting the app, the number of TCP connections between our app and the
>> repository server stays at only two.
>>
>> Is there some configuration for the TCP connection pool in the DavEx
>> client?
>>
>

Mime
View raw message