After doing some profiling, I think the reason is that where a user does not 
exist search has to be used to verify that it does not exist prior to adding 
the user. Using Yourkit I see about 55% of the time spent in the Lucene index 
performing a query triggered in UserManagerImpl.getUserNode(userId).

I assume that this query is needed because user nodes can exist in many places 
in in the repo under /rep:security/rep:authorizables so the path cannot be 
inferred from the username ?

Was there some design criteria that made this necessary, and is there any way 
to avoid the search on create.

I think this search must happen in every session that hasn't seen the user 
before which must be slowing almost everything where these isnt a pooled 
session down ?

Ian

On 5 Mar 2010, at 11:08, Ian Boston wrote:

> Hi,
> I am trying to optimise a bit of code that adds users to jackrabbit, I have a 
> lot of users to load.
> 
> Are these times unreasonable for Jackrabbit.
> 
> It takes 15ms to get the user with a call like 
> 
>      String principalName = "newUserId"
>      Authorizable authorizable = userManager.getAuthorizable(principalName);
> 
> user does not exist.
> 
> It takes 44ms to create a user with a call like
> 
>        User user = userManager.createUser(principalName, pass, p, prefix);
> 
> prefix is something line "aa/bb/cc/dd"
> 
> aa,bb,cc,dd all exist, and should be in memory and dd has < 255 children
> 
> I also create about 5 other nodes add some simple ACL's and the whole 
> operation takes upto 250ms.
> 
> I am a bit worried, since on in other RDBMS based  systems, that this will be 
> compared against, this sort of operation is faster,
> 
> deployers need to add in the range 10K to 4M, at the top end thats going to 
> take11 days to load if there is no slow down.
> 
> Any suggestions how to make node creation faster?
> Is there some magic trick that I am missing?
> 
> Jackrabbit 1.6
> Java 1.6
> OOTB standard config with Derby as a back end.
> MacBook Pro, 2.53 Ghz Intel Core 2 Duo 4GB DDR3
> 
> 
> Thanks
> Ian

Reply via email to