@atombeat:allow link extensions and list collection performance
Alistair Miles
AtomBeat 0.2-alpha-10 includes some performance improvements that should
hopefully speed up listing a collection (e.g., of studies) where the
@atombeat:allow link extension attribute is in use.
How much of a performance improvement you'll get depends on various factors,
including how the access control lists are being used, and so your mileage may
vary (I've seen it go between 2 and 6 times faster, depending on how ACLs are
used). If you do get around to trying the upgrade, I'd recommend doing a bit of
benchmarking both before and after the upgrade.
Also, let me know when you do the upgrade, I'd like to have a look at the XQuery
profiler for the chassis list studies operation. I'm sorry I haven't actually
tested this on the chassis data and configuration myself, I've just run out of
time. I have tested this on a fairly similar collection, but the devil is in the
detail here and chassis may be different.
Also, please note that, although you should see a performance improvement,
calculating values for the @atombeat:allow attribute remains an expensive
operation, and will still dominate the cost of generating a feed. So in future
chassis releases I recommend avoiding the use of @atombeat:allow in the
'entry-in-feed' context wherever possible. This may mean having to changing the
user interface slightly, e.g., to not have delete buttons in the studies table,
but only show the delete button when viewing a single study.
I would also recommend considering the use of the new paging plugin for
collections with more than 100 members. This plugin allows you to page through a
large collection, similar to the way you page through results from a google
search. The important thing from a performance point of view is that expensive
augmentations of the entries in the feed (such as decorating links with
@atombeat:allow) is done *after* the page is constructed as a subsequence from
the complete feed, and so the costs of using the link extensions plugin should
remain constant as the size of the collection grows. I.e., you should be able to
scale up to thousands of collection members and still use @atombeat:allow in the
'entry-in-feed' context, as performance will depend mostly on the page size and
not on the collection size (although this will probably change if you ever got
to 100,000 members or more).
Hope that helps,
Alistair
--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alim...@gmail.com
Tel: +44 (0)1865 287669