Some of you might wonder what we are currently working on for the upcoming Magnolia 3.6 release. There are four enhancements which I will highlight in this blog entry:
- Performance
- Caching (API & Strategies)
- Backup / Migration
- Transactional Activation
In essence, Magnolia 3.6 will ease maintenance, boost performance and strengthen the robustness or our content management system in production environments.
Performance:
When talking about performance improvements, I mean significant improvements which are mainly beneficial for authors who create and manage content within Magnolia. Magnolia 3.6 will be up to 10 times faster for example when creating paragraphs, activating content, managing revisions, importing content, and more.
These improvements are mainly possible because we reduced the usage of mix:versionable (MAGNOLIA-2086).Additionally, we were also able to solve the memory related issues (MAGNOLIA-1998, MAGNOLIA-2099) and have already back ported the solution to Magnolia 3.5.
Caching:
We already finished development of a new and better API from scratch for Magnolia 3.6 which allows granular custom flushing and caching strategies. The new cache system allows to implement individual cache solutions which optimally meet the load patterns of a website to ensure high availability of every single content element. The default implementation is built on top of ehcache. The enterprise edition of Magnolia 3.6 will include pre-defined caching solutions that will substantially increase the number of requests served by Magnolia when hitting a cached page, the mechanism being that pages will be cached in the background before the existing cache for visited pages is being flushed. The solution also ensures that only one request truggers the caching process if multiple requests ask for the same not yet cached content.
Backup:
We wrote a backup facility which allows to restore revisions of content as well. This was not possible before, because only the latest version of a page has been imported in releases prior to Magnolia 3.6. Under the hood, the new backup happens in a persistence independent manner, which was not possible with jcr imports before. The new backup feature will be a nice tool for migrations from one persistence to another. This would be needed if you change the database or wish to profit from the new bundled persistence provided by jackrabbit 1.4).
Transactional Activation:
In former Magnolia versions there was no mechanism guaranteeing that newly created or updated content is being propagated to all public instances (so called “subscribers”) in a staging environment. In Magnolia 3.6, such content gets ether published to all public instances or not at all due to the new transactional activation functionality.
The content will be sent to each public instance at the same time so that the single publishing request does not get cumulated any more as in previous Magnolia releases. The transactional activation feature of Magnolia 3.6 makes sure that changes are only committed and published effectively once the content reached all subscriber instances successfully.
I am eager to explore this version in production :-)
If you would like to read more about the technical details of the upcoming Magnolia 3.6 release, visit the Magnolia Development Wiki. This is the place where we have today started to make our internal concepts, roadmaps and backlog available publicly. Please note the comment functionality at the bottom of each Wiki page – you are invited to add information or leave a question there.
Just in case you don't have an account for our Wiki yet, feel free to register.
Wednesday, May 14, 2008
Friday, May 9, 2008
Memory Fix, Backport to 3.5
OK a backport to 3.5 was possible and the tests were successful. We will release a 3.5.5 containing this changes.
Further improvements, like having a mbean to reinitialize the system sessions, will be done for 3.6. I will now compare the two strategies to make a final decision what we make the default:
a) JCRSessionPerThreadSystemContext (would be saver as the sessions are not shared)
b) SingleJCRSessionSystemContext (used in current tests)
The main issue with a) was that the observation stops when you close a session so I had to add a hack to check for active observations and prevent closing in that case. But I would still prefer a) as each thread has its own session (thread save, sessions are alway up to date)
Further improvements, like having a mbean to reinitialize the system sessions, will be done for 3.6. I will now compare the two strategies to make a final decision what we make the default:
a) JCRSessionPerThreadSystemContext (would be saver as the sessions are not shared)
b) SingleJCRSessionSystemContext (used in current tests)
The main issue with a) was that the observation stops when you close a session so I had to add a hack to check for active observations and prevent closing in that case. But I would still prefer a) as each thread has its own session (thread save, sessions are alway up to date)
Performance
As I noted on MAGNOLIA-1998, the 3.6 version has a much better memory behavior and also performs much better (up to 8 times faster).
The relevant changes were done by solving MAGNOLIA-2099 (memory) and Magnolia-2086 (performance)
What I try now to do is to merge the memory related changes to the 3.5 branch so that a potential 3.5.5 could provide similar memory improvements.
But the performance enhancements will be part of 3.6 only I do also expect that we can't reach the same memory behavior in 3.5 as for 3.6
So I'm quite happy with the improvements ;-)
The relevant changes were done by solving MAGNOLIA-2099 (memory) and Magnolia-2086 (performance)
What I try now to do is to merge the memory related changes to the 3.5 branch so that a potential 3.5.5 could provide similar memory improvements.
But the performance enhancements will be part of 3.6 only I do also expect that we can't reach the same memory behavior in 3.5 as for 3.6
So I'm quite happy with the improvements ;-)
Subscribe to:
Posts (Atom)
Posts
