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 Mon, 11 Jul 2011 15:46:35 GMT
Thank you Chad for this feedback.

We are currently testing our application with an embedded Jackrabbit.
Depending on the results we will get, we will decide to investigate more
with the davex client or to move to a embedded + cluster solution.

John

2011/7/8 ChadDavis <chadmichaeldavis@gmail.com>

> > 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.
> >
>
> I think you may have allowed too many connections.  I created a patch
> to allow for configuration of this value and I've tweaked it quite a
> bit while executing load testing.  I've found that you can balance the
> load between the "repo server" and the client app.  In my case, I know
> that 200 connections would allow my app ( a jetty based web
> application ) to overrun my repo server ( the standard jackrabbit
> server deployed on jetty also ) by quite a bit.  I actually found
> great performance improvements, in relative terms, with a value of
> about 10-20 connections.
>
> > We are very interested in any feedback about the DavEx setup and
> > performance.
>
> I'm working on it now.  I just posted another thread regarding another
> issue I found.  When you raise the connections limit, there appears to
> be a concurrency issue in the davex client stack.
>

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