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 <[email protected]> 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 <[email protected]> > >> 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? >> >
