True, but we have some images on our site. One thing I just noticed. Some of our images are rendered in the "here" context not in the portal_url context. That means they don't look like cache hits. Just something to watch out for.

Ah.. Good point. I'll check to see how our images are rendered.

I noticed in the 2.7.1b1 release that the line is not commented out (i.e. they fixed this).

That's good.

Finally, have you had any experience caching portlets in Plone. It is not at all clear to me how to do it. Benchmarking showed that a big issue for us was the navigation tree generation. I'm frustrated by the fact that all the Plone documentation is still written for "slots" and that the newer version of Plone didn't get rid of all the complications described in the old documentation related to caching.

Yes, documentation is pretty scarce when it comes to best practice caching. It seems that caching is more of an art than a science. What we are doing is the following: Define a page template 'cache_Calendar' and put it in your custom skin folder (or whereever): <tal:calendar define="dummy python:request.set('anchor_url', request.URL0); dummy python:request.set('anchor_method', '');"> <metal:getcal metal:use-macro="here/portlet_calendar/macros/portlet" /> </tal:calendar> And then associate this template to the RAMCache. REQUEST variables should be: b_start month year Then in your right_slots, you would use: portal/cache_Calendar Instead of: here/portlet_calendar/macros/portlet

...

For use with Apache and Squid where there is HTTP caching going on, then yes, this change is necessary. But as I mentioned above, for RAM caches it doesn't make any difference.

I'm eager to hear what the Zope guys say on this issue. What is the link to the thread?

Its on the Zope mailing list. I'm not sure how I could send it to you as a link. You might try and find out where the Zope mailing list archive is.

The thread is here: http://thread.gmane.org/gmane.comp.web.zope.general/37337 Nate