jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Tranier <tran...@gmail.com>
Subject Re: DavEx Remoting Performance
Date Tue, 21 Jun 2011 16:12:44 GMT

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
Do you think that several embedded repositories within a cluster is a better
setup than DavEx regarding scalability ?


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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message