Re: DavEx Remoting Performance

[ChadDavis <ch...@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.

Re: DavEx Remoting Performance

[ChadDavis <ch...@gmail.com>]

On Mon, Jul 11, 2011 at 9:46 AM, John Tranier <tr...@gmail.com> wrote:
> 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.
>

FYI: I've made several significant improvements to the davex
performance.  If you come back to it, let me know.  I'll probably try
to submit some patches in the next week.

Re: DavEx Remoting Performance

[John Tranier <tr...@gmail.com>]

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 <ch...@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.
>