Forums / Developer / static cache - some user report & tips ...

static cache - some user report & tips ...

Author Message

Georg Franz

Monday 27 June 2005 12:27:21 pm

Hi folks,

i am really happy with the static cache feature in ezp 3.6. The speed of my websites is fantastic now.

I've upgraded the sites
http://www.kuh.at
http://www.galaxis.at

from ezp 3.5 to 3.6.

The speed improvement is incredible ... no more fear to be nailed by search engine robots and massive multiple page requests ...

Some tips and common pitfalls:
-) If you use static cache, you have to remove all dynamic content. Sounds easy, but isn't. Most common "dynamic content" is the "user box" with the login inputs or info.

I created an article and a special override template. That article isn't cached and shows the login-box if the user is anonymous or the user information (like edit page etc.) if he is logged in.

-) If you have banners on your page you can show them with javascript.

-) If you have counter on your page, use an external service (include it with javascript) - or write your own one.

-) If you like to expire the static cache by time (e.g. you like to have a new homepage at least once a day) - create a dummy class (which isnt shown on the user site) and publish an object of this dummy class once a day in a cronjob.
(That's necerssary because deleting of the index.html isn't enough, it won't be recreated without publishing.)

-) Don't use static cache if you have 2 different sites in the same database and you are using the virtual host system.

-) Don't use staticcache if you use the "pathprefix" setting in site.ini. (I've filed a bug report already about that issue. http://ez.no/community/bugs/static_cache_path_prefix_isn_t_working_anymore )

-) If you have content like forum postings which can be created by registered users only: Think about allowing anonymous users to create them.

-) After running the makestaticcache.php you will have a lot of session entries in your ezsession table. (The scipt simulates a normal http-request, so one new session entry is produced for each page which is cached ...) So, think about clearing the session table if you have to run the script often and you have to cache thousands of pages ...

-) If you have a large site, think about the order of the static cache entries in the staticcache.ini.append:

CachedURLArray[]
CachedURLArray[]=/
CachedURLArray[]=/news
CachedURLArray[]=/news/*
CachedURLArray[]=/info
CachedURLArray[]=/info/*

Better is:
CachedURLArray[]
CachedURLArray[]=/
CachedURLArray[]=/news
CachedURLArray[]=/info
CachedURLArray[]=/news/*
CachedURLArray[]=/info/*

So in that case the /info is cached before the children of "/news" by the script.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Frederik Holljen

Tuesday 28 June 2005 1:31:32 am

Thanks for a lot of good information Georg. We are going to write a good doc page for the static cache and I'll make sure your tips are included.

Geraint Edwards

Wednesday 29 June 2005 12:50:05 am

Thanks for the pointers. If you have a minute can you clarify one of your points - you say <i>you have to remove all dynamic content</i>. Do you mean within a specific tpl file or within a "delivered" page (i.e. the final full page sent by the web server)?

* If the answer is removing dynamic content from specific tpl files (e.g. pagelayout.tpl), can you <i>include</i> external templates that encapsulate any dynamic content you wish to deliver as part of the page (I guess via shtml in the resultant static cache)?
* If the answer is removing <b>all</b> dynamic content from the served page and you have limited dynamic user/date specific content e.g. displaying user name, do you use cookies to pass the info to javascript in the page that can manipulate your "dynamic" content?

thanks

Geraint

Georg Franz

Wednesday 29 June 2005 8:34:03 am

Hi Geraint,

as you probably know meanwhile: That's the main limitation of static cache: You can't have any session information or user information and stuff like that on a page which is static.

But there should be an easy way to get the info if the current visitor is logged into the system.

For other readers: I wrote another topic for that:
http://ez.no/community/forum/developer/static_cache_get_user_login_information_by_cookie_js

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Daniel Beyer

Friday 13 January 2006 10:37:36 am

Hi Georg,

we just released a patch allowing to use PathPrefix with static cache. I think you find this intersting as you already posted a bug about this issue: http://ez.no/bugs/view/6780

You can find the patch for 3.6.4 at pubsvn:
http://pubsvn.ez.no/community/trunk/hacks/staticcache_with_path_prefix/

Greetings, Daniel.

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Björn Dieding@xrow.de

Tuesday 26 February 2008 4:02:23 pm

quite old topic... not much interest anymore... I removed the sticky...

I think people should start using reverse proxies over static cache.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Russell Michell

Sunday 06 April 2008 4:04:04 pm

"quite old topic... not much interest anymore... I removed the sticky..."

On the contrary, I would suggest there is a lot interest in what you call "Static Cache" (other descriptions are "Static content export", "Static Deployment" etc). Plone has had this functionality, allbeit as a free plug-in, for years.

The up-and-coming (very cool) Silverstripe CMS (www.silverstripe.com) already has this basic built-in and the developers are actively working on improving it for "Enterprise" class interface and functionality.

"I think people should start using reverse proxies over static cache."

For some organisations such as ours, the overhead in managing, configuring and maintaining a reverse-proxy was such that it was no-hassle at all in comparison to simply employ a system that generated flat HTML from dynamic content.

We have no use for public logins, calendar or forum functionality, just data that is occasionally requested in massive numbers - in very, very short timespan.

I am actively looking at ezPublish for a replacement for our current CMS, and its ability to create a static "cached" representation of files and file hierarchy is an absolute key component to our using it or not.

Thanks to the other posters to this thread, very useful information. :-)

Russell Michell, Wellington, New Zealand.
We're building! http://www.theruss.com/blog/
I'm on Twitter: http://twitter.com/therussdotcom

Believe nothing, consider everything.