20 Mar
2009
20 Mar
'09
8:16 p.m.
On Fri, Mar 20, 2009 at 10:48 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
I think it is important to finally do some profiling
and improve the
bottlenecks. One thing that's been causing a lot of problems is the
attachments storage that's a memory hog. Another is excessive cloning of
XWikiDocument objects, which should be improved by both improving the
clone performance and reducing the number of clones created.
What about just using the filesystem to store attachment files 'as-is'. Use
the database to hold the filename and it's relation to the unique identifier
that is the filename. Use separate directories representing wikis, and
subdirectries representing spaces. I.e. each space has it's own directory of
attachments all filenames per directory unique. This implementation
will not do attachment versioning or attachment recycle-bin which will be
forced ''off'. If you delete an attachment, you'll just have to go back
to
where you got it from originally and get another....
In other words, I think there should be a xwiki.cfg switch which says
whether to use external attachments or not, and migration tools that migrate
attachments from the database to the filesystem for systems where this new
feature gets "turned on." Leave it off and continue to get the old behavior
with database-based attachments.
Alternately, at least, turn off attachment versioning and recycle-bin by
default. Preventing problems like this
http://n2.nabble.com/Hibernate-exception-when-trying-to-delete-attachment-t…
-- Niels
http://nielsmayer.com