jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hartmann <andr...@apache.org>
Subject Re: Scalability concerns, Alfresco performance tests
Date Mon, 04 Dec 2006 14:17:52 GMT

thanks for the clarification!

David Nuescheler schrieb:
> Hi Andreas,
>> Now, a news message [1] on TheServerSide about benchmarks provided
>> by Alfresco to prove the superiority
> ermhh.... let's say "state" not "prove" ;)

Agreed, my wording was quite provoking, this was not intended :)


>> "From what we've seen, Alfresco is comparable to JackRabbit for small
>> case scenarios - but Alfresco is much more scalable [...]"
>> Do you agree to this statement? If yes - are these problems related
>> to the persistence manager abstraction? Is this a known issue, and
>> will it be addressed?
> I do not even remotely agree with this statement.
> Jackrabbit has been built to scale freely in size.

That's good to know.

In your answer on TheServerSide, you said that "Scalability is mainly
a matter of choosing and configuring the persistence layer correctly."
Are there any scenario recommendations / best practises available?
I'll check out the website again, but insider knowledge is as always
greatly appreciated.


> "Backup/Restore" operations in my experience usually happen on the
> persistence layer, which means that restore operation (obviously) does
> not go through the normal user API.

How would a transactional replication be implemented (e.g. from an
authoring system to a live system in a DMZ)? If a lot of documents
are involved, for instance after an URL change which affects a lot
of links, this could probably lead to such a massive transaction.
Should this be implemented by accessing the persistence layer directly?
IIUC this would have the drawback that the JCR implementation couldn't
be replaced without changing the replication code ...

> I actually would go as far as stating
> that it would be close to abuse of the API to go through the transient
> layer
> to restore an entire content repository.
> We are currently working on a solution for that, but since nobody had
> a pressing need, it had a relatively low priority. If this is a pressing
> issue for your project 

I hope it won't be :)

Thanks a lot,

-- Andreas

View raw message