jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Bologna <alessandro.bolo...@gmail.com>
Subject Re: Database Connections and Performance
Date Wed, 29 Apr 2009 04:23:16 GMT
Hi guys,
just would like to clarify that Jackrabbit does *not* uses the databases for
queries, even if you use the sql-like syntax.

Queries are executed by the JVM against the Lucene indexes (which are stored
on your local disk). The result of these queries is (maybe I am simplifying
a bit) a sequence of uuid that then are used to retrieve the corresponding
serialized node data from the DB. The only type of "query" you would see on
the database is to retrieve the corresponding nodes (something along the
lines of 'select * from table where uuid='...')

So, the number of concurrent connections to the database has very little to
do with how fast your queries will execute.

If you experience a slowdown with many users, and you are sure that the
issue is in the JCR queries, you will benefit from more memory on you app
server, faster cpus(s) and potentially a faster local disk. If none of these
help (or is not feasible for you), try to revisit your queries. In some
cases, you may be able to do without them, or simplify them. Read this post
see if it helps to optimize them a bit.


On Tue, Apr 28, 2009 at 11:06 AM, Ian Boston <ieb@tfd.co.uk> wrote:

> 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.
> eg
> 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.
> Ian
>> --
>> 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.

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