On Wed, Mar 17, 2010 at 7:42 PM, Thomas Müller <thomas.muel...@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 are - 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. cheers stefan > >> cut some features to gian performance improvement. > > I'm not sure. What features could be cut? > > Regards, > Thomas >
