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 Wed, 22 Jun 2011 07:35:44 GMT
Hi Toby,

We have checked that the sessions are effectively closed.
We're not using a single session, but a session per user which is
automatically closed at the end of http request.

The change pooling thread seems to be related to the number of HttpClient
since the overload appears much faster when we do not provide the default
workspace name at login.

We will try the patch you mention to mesure the impact with our testcase.

Regards,
John


2011/6/21 Tobias Bocanegra <tripod@adobe.com>

> hi,
>
> > Sc-write - 80 concurrent users : the run is interrupted by an overload of
> > many threads running changePolling method
>
> be sure to logout the session after the test - otherwise the change
> polling thread will never stop. there is also work in progress to only
> create the thread on demand [0].
>
> regards, toby
>
> [0] https://issues.apache.org/jira/browse/JCR-2995
>
> On Tue, Jun 21, 2011 at 9: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message