some words about caching

Ist zwar in englisch, aber vielleicht interessiert's hier ja trotzdem
wer (so als Zugabe zu meinem Popoon Vortrag letzthin an der EB )
***
Hi

Some parts of Bitflux CMS (and more exactly popoon) can get quite slow
when you have big documents or big sites, therefore we are right now
implementing (or already have) some sorts of caching mechanisms. I'll
make a quick overview:

- Sitemap caching. Already implemented. We generated with the help of an
xslt out of the sitemap a php file. The second time, the sitemap is
called, just this php file is executed, no need to transform sitemap.xml
again. Besides avoiding the transformation, the php-file can also be
cached by Zend/PHP-Accelerator/apc, therefore the speed gain can be even
more. This php-file could certainly see some more enhancements, but it's
a good start IMHO

- component caching. Component caching was implemented by Hannes Gassert
in the last few weeks. I didn't have the time to check it out till now,
so I still can't judge it :) But component caching is more or less, what
cocoon does with caching. It caches the single
generators/transformers/serializers. Some more info about it can be
found at http://bugs.bitflux.ch/show_bug.cgi?id=23 (beginning in german
end in english) and http://chregu.tv/popoon/pres/ (slides from the
Frankfurt PHP Conf in german). I hope, I can look into that stuff soon
and inform you more about it here. component caching should certainly
improve the speed a lot even with quite dynamic pages.

- output caching: Output Caching improves your speed a lot, if you have
more or less static pages (static in the sense of "Does not change with
every request"). OutputCaching looks at the URL and if this URL is
already in the Cache, it just outputs it without even calling the whole
popoon/sitemap stuff. At the moment (within Bitflux CMS), output caching
is only integrated in the index.php of $BX_PROJECT_DIR/www/index.php and
therefore quite dump (but enough for for example our webpage, if we
change something, then it just deletes to whole cache, which is ok for
us). Later we'd like to implement this into popoon.php for more
intelligent/adjustable output caching (see
http://bugs.bitflux.ch/show_bug.cgi?id=52 for some details)

- generators/bitflux.php caching: bitflux.php seems to be the bottleneck
in performance, or more accurate the db2xml transformation within that.
Therefore I will add a mechanism, which will check the database if some
relevant entries have changed, and if they didn't, we just load the
pre-generated XML from the cache without having to call the db2xml
transformation each time. This will be done for every bxst:section in
the different structure.xml files. This has the advantage, that for
example the tree-section, which does seldom change, is pulled from the
cache, even if some other sections (content from the page section) has
changed. I made some very basic implementation for that and it really
does speed things up. Furthermore we will also cache the structure.xml,
because the transformation from this xml-structure to a SQL-query does
not have to be done everytime :)

- Zend/PHP-Accelerator caching. Should be known by most people. It has
nothing to do with popoon/BXCMS but just keeps the compiled PHP-files in
memory. Since we have quite a lot of files and classes, it's quite
useful (and PHP-Accelerator is even free :) ). Some simple benchmarks
show a doubling of the p/sec delivered.

That's it for a quick overview of "How to improve the speed of BXCMS?"
:)

If you have questions, do not hesitate to ask them here.

chregu

-- 
christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 |  fax +41 1 240 56 71
http://www.bitflux.ch  |  [email protected]  |  gnupg-keyid 0x5CE1DECB