caching - magento open source full page cache

Question

I was speaking to a developer recently who said that no magento CE full page cache worked perfectly even with a default install.

my experience of this is the same.

if you use aoe_static's awesome module and phoenix's full page cache with varnish module you will get close.

with the aoe_static module caching is done on a per Action basis which seems sensible to me. hole punching is done with placeholders applied via layout xml and dynamic blocks requested via a ajax call which won't be cached. cookies are set with this call as well. he provides a default vcl which is works with varnish 2 (i never checked) and can be easily changed for varnish 3.

cache invalidation is handled quite well by the phoenix module. you can see the methods in the control folder in the module. this takes care of cache invalidation when products or categories are changed and invalidates both product pages and category pages. however the url's generated by the layered nav are likely to be cached (depending on your vcl). these are not invalidated, so watch out folks.

i'd really like to know if any other problems exist with these modules before i use them on production sites. if anyone could point me to a problem i'd be happy to try and post a solution.

but for the layered nav url's a model would be required to log the generated url's with category id. i suppose it would be simple to have a 2 column model - url and category - and then cache invalidation would need to check the model and invalidate the extra url. this should be done at the same time as the main category url gets done. doesn't sound too bad. if anyone gets my very brief explanation please advise on if i'm missing something before i waste my time.

i would rather create an open source project with some community help (or someone more experienced at the lead) that has a (deserved) reputation for reliability in a default 1.7 install at least. i think the most sensible thing would be to create one module with all the edge cases (for a default 1.7 install) covered or documented.

does anyone know how to go about such a mission? if there was more community support to do this with apc or memcached that might be more sensible for wider hosting availability. the logic or the development time wouldn't change much.

this could be expanded to cover session caching of blocks which should be kept in mind but i think focus on a reliable full page cache should be the priority.

you can also detect devices in a vcl. this could be added to shops wanting mobile version https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl

i've created an email for this project so if you want to be involved it's "magefpc gmail com". anyone with experience of magento, git and debugging would be welcome.

thanks

Answer 1

1 problem what you might have with aoe_static is, that currently the extension doesnt log products so statistics in backend about viewed products are not updated. this was added recently as TODO note into the github.

problem with varnish and magento cache is, that magento cache parts of pages, blocks and varnish does cache whole pages. so even though phoenix solution have observers in place and reset varnish accordingly on product/category update, you still have blocks in magento what have to be reseted. aoe_static try's to solve this, but it does only for visible blocks on the page. but other parts of magento, as layered navigation, might be reseted as well internally on product/category update, but than are not reset in varnish. there are 2 solutions. either identify every part of magento on frontend whats not reset after product/category update and apply aoe_static solution to it. that would mean you would have to load layered nav via ajax. or the second solution is, to add more logic into phoenix extension to invalidate more varnish pages.

i have couple of custom extensions (pages what display products) and i build logic to invalidate those extensions each time product/category is updated. now im working on search, as this needs to be invalidated as well, but the complicated part is, to work around blocks and cache invalidation logic.

overall, proper cache invalidation is one of the hardest part of web development.