On Fri, Mar 20, 2009 at 10:48 AM, Sergiu Dumitriu <[email protected]> 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-td... -- Niels http://nielsmayer.com