Modeshape Performance

[kbachl]

Hello,

I'm using modeshape (2.7.0.Final) as a backend to an CMS. During and JMeter session using 25 threads hammering on 3 pages of it (on my glassfish 3.1 launched within IDEA) i got the following results:

As you can see most time is wasted within:

1. FederatedRequest.await (27,8%)

2. JcrRepository.login (11,8%)

3. InMemoryRepository.startTransaction (10,5%)

4. RepositoryConnectionPool.getConnection (8,1%)

making these 4 functions relevant for 58,2% overall CPU usage; The used connector was the InMemory one, but tests with DiskConnector showed similar results (only start transaction was different); Interestingly the overall output of my CMS didnt change when swapping from DiskConnector to InMemory one; The numbers in JMeter changed from 1550 pages/ minute to 1620 pages/ minute - a very very minor change;

Any ideas why so much time is consumed in these places?

Best,

[rhauch]

Offhand, these are some possible reasons why you might be seeing these results:

1. FederatedRequest.await -- The federated connector works by creating and enqueuing the requests to the different underlying connectors (translating any path changes due to the projections), where the enqueued requests are sent to the connectors via a worker pool. This way, the connectors can start processing the request while the federated connector is still walking through the original requests. But after the federated connector finishes enqueuing the requests, it needs to wait until all of the requests are finished before it can return. So IMO, this is somewhat of an anomaly in how the measurement is being made, because your tests are only measuring how long (clock time) the "await" method takes, and does not measure CPU.
2. JcrRepository.login - Not sure what might be taking the time here. Are you using JAAS or a custom authentication provider?
3. InMemoryRepository.startTransaction - the InMemory connector uses a global write lock, which might be the problem here. Note that the InMemory connector is not often used in production. Each connector is a bit different, too.
4. RepositoryConnectionPool.getConnection - This sounds like the pool is not configured well for your machine, and that you're allowing more threads than what can be used.

[kbachl]

Thank you for answering, regarding the points:

1. ok, this explains it;

2. this is odd, as I rely on the anonymous login method.....

3. InMemory was the test to ignore any impact from my usually used DiskStore  - what connectors are good for heavy concurrent access?

4. How can the pool be configured - or better said: where is it configured?