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. <

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.

Answer 2

i'd like this post to be a community answer detailing approaches to particular handles and suggested caching and invalidation logic needed if it's not already included in the phoenix or aoe_static module. basically caching will be done by module/controller/action pattern laid out in the aoe_static module and most of the existing invalidation exists in the Phoenix module.

so we need to decide which blocks should be rendered via ajax and where addition cache invalidation is required. like gondo says you'll need to add a lot more invalidation logic to cache searches. i plan to start smaller with the catalog, cms and aw blog pages, much has been done here but a little more is required. if we could add search too, with the help from gondo :), that would be great.

for instance - widget instances could be a problem, as could static block saves. this can (as far as my very quick investigation has shown) be easily solved only by running a total cache invalidation using the event dispatched by the core_model_abstract method _beforeSave()

  Mage::dispatchEvent('model_save_before', array('object'=>$this));

we'd need to match the type of model before invalidating the entire cache. this pattern will also be a real time saver in other difficult areas of cache invalidation. using the instanceof method is fine but we'll need to know model names to check for. i guess community involvement is great here because the code's so easy but so is missing a model.

widgets are essentially the same from frontend point of view. the one with products should be loaded with aoe_static, as they are changing quite often. but the static ones can be treated as static (html) blocks.

we don't want to invalidate the entire cache when a product is saved and can't check if the product has been included in a widget. but the aoe_static module works with layout rendering. widgets will need to be included via layout xml and not in the admin wysiwyg as the often are. these widgets could be added to the call controller handle and place holders to what ever handle is needed.

full varnish invalidation, time to time, is not a bed thing. the whole cache invalidation is an issue if it happens too often, or if it does not happen when needed. the main goal should be to capture every invalidation scenario and trigger notice in admin panel, same type of message as you get when you save product: "One or more of the Cache Types are invalidated..." this way admin can make the decision if he/she wants to invalidate cache manually or wait. and ofc there can be some automatic invalidation logic build in based on this scenarios.

also the model must be created to store the url's created by layered nav and these should be invalidated along with the category view url's.

and with layered nav and invalidation in general in mind we must invalidate the entire cache when an attribute is saved (i think).

we should be able to put the product reviews on the product page without ajax for seo purposes.

this means when a review model is saved it must be checked using the model_save_before event and we should invalidate the product page url. this save changes the rating but i suggest this block is grabbed in the ajax call. it's not important for seo. this goes for the product view and list pages.

we could also cache and invalidate review module pages but this isn't important to the majority of users and should wait.

who wants tags blocks. these can't be loaded by ajax it defeats their purpose. at the same time they're not worth our efforts now imo.

if you cache url's with the session id appended it will cause users to get each others sessions i'm told. i think this is easily solved by piping in vcl_fetch based on a regex.

this answer is getting messy and should be redrafted sometime soon. feel free to add your 2 cents!!