Forums / Install & configuration / How far can I take static cache?

How far can I take static cache?

Next topic

Author	Message
Seth Gottlieb	Tuesday 13 March 2007 7:53:21 pm I am working with a client that would prefer a "baking" style CMS where all the pages are pre-generated and then served by a basic web server. How close can static cache get to this model? If I set CachedURLArray[]=/* Will every page on the site get cached? What overhead would eZ publish add? For example, does it query the database to translate virtual urls to system urls? Does index.php stream down the contents of the html files cached on the file system? Also, are any really high traffic sites intensively using static cache? Thanks, Seth
Christian Johansen	Wednesday 14 March 2007 2:54:22 am You can take static cache all the way! :) There's no faster way to serve eZ Publish pages. You can even get away with a server that doesn't even have PHP installed if you either move the cache files manually or with a script of some sort. eZ Publish creates a static cache by generating fully functional static HTML pages and then uses Apache mod_rewrite to redirect directly to these files if they exist. This means that when a page is statically cached, the request won't even get to eZ Publish at all. It goes straight from the .htaccess (or VirtualHost in httpd.conf) rewrite to the html file.
Seth Gottlieb	Wednesday 14 March 2007 7:19:09 am This is perfect. Is there any documentation that shows how to configure a site in this way?
Bruce Morrison	Wednesday 14 March 2007 6:02:19 pm Hi Seth There are a number of things to watch with the static cache: + If a static copy of a pages doesn't exist on the file system then eZ is used to serve the page. + You manually generate the initial static cache then pages are regenerated after publishing. Beware running this script on a running sight as it removes the static cache before regenerating it. This means that the site relies on eZ while the static cache is generated. + You have to make sure that the setup regenerates all the effected pages otherwise you can end up with old/dirty content on the site. + Only works for parts of the site that do not require login. If any part of the pagelayout is changed when the user logs in (basket, login form, personalisation etc) then you might need to reconsider the page design. + Of course will not work with things like search. (I'm pretty sure it is limited to the content module) + On heavily loaded sites it is good to use view cache pre-generation along with static caching as this minimises the time it takes to create the static version of the page. The static cache is great in that you can run a site with much lower speced hardware than if you use just eZ to serve the pages. If you remove the cache for any reason you might find yourself in trouble :) I've used the static caching on a site that is pretty quite for all but 4 days of the year. During those 4 days it goes off - lots of accesses and lots of updates. We used the static cache to help handle the load. We did find that the updates meant that pages like the home page were being generated quite often and the system was falling back to eZ to server the page. I ended up writing an extension that allowed for the content updates to be done in batches and for the static pages to be generated manually. I'll see about packaging it putting it up as a contribution. In some cases we've also used wget to generate static versions of eZ sites. This may be a simpler solution. Heres a couple of links http://ez.no/doc/ez_publish/technical_manual/3_6/reference/configuration_files/staticcache_ini http://ez.no/community/articles/ez_publish_performance_optimization_part_3_of_3_practical_cache_and_template_solutions/static_cache http://ez.no/community/forum/developer/static_cache_some_user_report_tips Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish