Note that there are some explanatory texts on larger screens.

plurals
  1. POmagento open source full page cache
    primarykey
    data
    text
    <p>I was speaking to a developer recently who said that no magento CE full page cache worked perfectly even with a default install.</p> <p>my experience of this is the same. </p> <p>if you use aoe_static's awesome module and phoenix's full page cache with varnish module you will get close. </p> <p>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. </p> <p>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.</p> <p>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. </p> <p>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.</p> <p>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. </p> <p>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. </p> <p>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. </p> <p>you can also detect devices in a vcl. this could be added to shops wanting mobile version <a href="https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl" rel="nofollow">https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl</a></p> <p>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. </p> <p>thanks </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. CONot really an answer, but we've used the Phoenix mouldule on a number of sites, and made a number of extensions around turning on/off caching based on certain events, and introduced a cookie based system for maintaining some user data client side. We maintain a public GitHub repo for our version of the module at https://github.com/aligent/Phoenix_VarnishCache ... We;ve also seen (but not used) Nexcess' Turpentine module (https://github.com/nexcess/magento-turpentine). Turpentine has a much simpler implementation, and looks interesting. We'd be happy to assist in any way we can.
      singulars
    2. COexcellent your offer is much appreciated! i looked at your code and it seems pretty sound but takes a very different approach. i believe we should wait a couple of weeks to see more variations and weigh up the pros and cons. anyways invalidation is needed for the layered nav url's but should tie into a complete module i believe
      singulars
    3. COi've thought a little more and am coming to the conclusion that i really like using the phoenix module and aoe_static's module. like i said your approach to dynamic content is very different. however your integration with the AW Blog is a brilliant idea and essential to most business's. i really think refactoring these elements and adding the cache invalidation i described into one module is a good approach. i'd like to check that the creators of the other modules would be happy with this and give something a go. what you think? we seem to be alone on this issue for now :(
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload