jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] MicroKernel prototype
Date Thu, 18 Mar 2010 09:53:13 GMT
On Wed, Mar 17, 2010 at 7:42 PM, Thomas Müller <thomas.mueller@day.com> wrote:
> Hi,
>> i doubt that the results of this comparison is any way significant.
> It was not supposed to be a fair comparison :-) Of course the
> prototype doesn't implement all features. For example path are parsed
> in a very simplistic way. I don't think the end result will be as fast
> as the prototype. Still, I do hope that the missing features will not
> slow down the code significantly if they are not used. And if they are
> used, the penalty shouldn't be too high.
> What is significant is: the prototype is not slower than the "full"
> Jackrabbit, even without the CachingHierarchyManager.

some of the 'missing' features are path-based (e.g. locking).
it's too early IMO to judge whether a caching hierarchy manager is
needed or not...

IMO the only statement that can be made based on your comparison
is that if the prototype with very limited functionality were slower than
jackrabbit with a fully implemented feature set, the protoype's architecture
would probably need to be reconsidered ;)

> For me that's
> relatively important because it would simplify the architecture. More
> tests are required to check if the current architecture works well
> even if there are millions of nodes and many concurrent sessions. And
> it's important to add more features of course.
> I'm wondering what is the *most* problematic features to verify the
> architecture:
> - security
> - orderable child nodes
> - same name siblings
> - locking
> - transactions
> - clustering
> - observation
> - workspaces
> - node types
> - large number of child nodes
> - search
> - correct path parsing and lookup
> - multiple sessions

in my experience the most critical features performance-wise

- security
- locking
- scalability (number of concurrent sessions and repository size)
- transactions

very flat hierarchies are performance-critical aswell.
however, since i consider them rather an edge case
i wouldn't focus on optimizing the architecture for this
very specific use case. i agree that we should support
it but performance for reasonably distributed hierarchies
(up to say 10k child entries per node) should be optimized
since this is probably the most common use case.


>> cut some features to gian performance improvement.
> I'm not sure. What features could be cut?
> Regards,
> Thomas

View raw message