jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Database Connections and Performance
Date Tue, 28 Apr 2009 15:06:37 GMT
Ok I should state that I haven't used OCM, but from looking at it I  
think it binds to javax.jcr.*
if not, ignore my comments (but please let me know so I learn :) )

On 28 Apr 2009, at 15:44, majohnst wrote:

> Thanks for the response. To give a little more information about my
> situation, we are not seeing excess sql traffic, we are more  
> concerned with
> the time required to execute a query from the repository.
> In our setup, we are using a Spring/Tomcat setup and using  
> Jackrabbit OCM to
> map our entities. We have noticed that as the number of concurrent  
> users on
> our website increases, the query performance goes way down. So our  
> page load
> times increase dramatically. As best as I can tell, the pages are  
> waiting
> for a jackrabbit query to execute and a backlog of jackrabbit  
> operations
> begins to form, slowing down the page loads. When you say jackrabbit  
> is
> multi-threaded:
> Ian Boston wrote:
>> Jackrabbit has its own multi threaded state management. Everything is
>> focused on serving information from memory and not performing a query
>> against the database. Only when a session needs to get something that
>> isn't in one of the shared caches will you see queries hitting the
>> database.
> Do you mean that it is executing queries against the repository in a
> multi-threaded way (many concurrent queries)?

I think we need to differentiate queries.

Queries above jackrabbit at the javax.jcr level are either direct  
(javax.jcr.Session.getNode() etc), indirect Node.getNode() or  
javax.jcr.query.*. All of these go through the jcr Session which is  
not thread safe but there will be 1000's and they will be able to  
access shared node state *without* generating SQL Queries.

So there can and will be many javax.jcr.* 'queries' all multi threaded.

AFAIK, java.sql.Connections are not generally thread safe (driver  
dependent) so SQL queries will be serialized even if multiple threads  
are requesting them.

> Since we are using spring in a
> web app, is this considered one session, or multiple sessions?

If spring uses a single java.jcr.Session then it will be one. I would  
expect it to use one per request thread.

> The ultimate
> goal is to increase the speed of our queries. We have already read  
> over the
> tips regarding how to write queries effectively and how to structure  
> the
> repository. Now I am thinking we are running into code issues either  
> with
> the Jackrabbit query logic or in OCM mapping that is slowing the  
> process
> down.

I think you need an OCM expert (not me sorry) as it could be that  
there is something going on there.

If you want to check that Jackrabbit itself is the problem, rather  
than OCM, try using apache benchmark against a JCR repository.

ab -c200 -n1000 http://localhost:8080/some/url/that/gets/the/content/of/a/jcr/file.html

ie 200 concurrent threads, each thread requesting 1000 times.


> -- 
> View this message in context: http://www.nabble.com/Database-Connections-and-Performance-tp23277508p23278564.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message