• Newsticker
• Compiling the PHP-Memcached 1.5 extension
• Using the MidCOM CLASS-style privileges
• New MgdSchema classes for MidCOM - Installation Instructions
• Introduction into the MidCOM ACL structures
• Gratulation an Wikipedia und an Steve Jackson Games
• MidCOM ACL tutorial
• MidCOM Database layer class API
• Why does MidCOM 2.6 need a DB abstraction layer?
• net.nemein.payments setup instructions
• MidCOM 2.4 finally released, and a outlook into the future
• New MidCOM configuration system in action
• Wir haben geheiratet
• Working with serialized MidgardObjects
• MidCOM 2.4. release delayed
• MidCOM E-Payment working
• Greetings from the Helsinki Midgard Meeting
• MidCOM 2.4 Status Report: Indexer Progress, Minor Goodies and Release Plans
• MidCOM Indexer setup instructions
• MidCOM 2.4 Status Report: Component Base-Classes (Part 2)
• MidCOM 2.4 Status report: Indexer, new Base-Classes and a dose of Plucene
• MidCOM 2.4 Upgrading Instructions
• MidCOM 2.4 Status Report: Indexer Progress
• MidCOM 2.4 Status Report: Metadata and Configuration
• Plucene again, and a few things about MidCOM Permalinks
• Plucene up and running, sort of...
• PLEX - the PLucene EXperience
• First steps in the MidCOM (P)Lucene integration
• AIS Onsite Toolbar Tutorial
• Linux 2.4 + Linux VServer + GRSecurity patch
• Further improvements to the MidCOM Toolbars
• MidCOM AIS toolbar brings MidCOM 2.0.0 closer
• MidCOM Filesystem Transition going well
• MidCOM Filesystem Transition started
• Nehmer.net IT Services online
• Videoverarbeitung unter Linux
• The Olymipic Military competition gold medal charade
• MidCOM UTF-8 Howto
• Sektion für die Shadowrun-Runde München angelegt
• Neue Shadowrun Abenteuer- und Kampagnenbände
• Neues Zeugnis in den Bewerbungsunterlagen
• Nathan Syntronics - Relaunch
• Nathan Syntronics

MidCOM 2.4. release delayed
2005-04-20 21:56

The MidCOM 2.4 release, scheduled for the next weeks, will be delayed. Reasons are the performance problems of the reworked NAP/Metadata subsystem. MidCOM Core will stay in feature freeze nevertheless, the only change that will be made is the introduction of a caching engine for NAP information, which is rather query intensive.

Due to the limited query facilities of Midgard, the MidCOM NAP code grew quite slow during the last enhancements added during the development of 2.4. Main reason for this is that now every object has to be loaded from the database at least once from NAP, as it creates the metadata object and verifies visibility of the object. While this object is reused in NAP, it is not possible to "transfer" the object to other HTTP requests.

This leads to extremly high database traffic, which is the main reason for the current speed problems. Optimization of the database queries is not yet possible, and will have to wait until the Midgard Query Builder reaches maturity.

Until then (and perhaps even then) I will introduce a cache database for NAP which will speed up allmost all read-accesses to the information related to the NAP tree. The cache data will be created on demand, and invalidated as selectivly as possible, with an per-object granularity.