The cache backend Cm_Diehard_Model_Backend_Magento is currently broken in many places.
It seems that the dynamic block implementation was never fully functional.
I'll see if I can fix it since I'm curious to how it preforms. Once I get it running I'll send a PR.

I was wondering if it would make sense to add support for ajax and browser local storage as holepunching mechanisms.

That way, the entire page response could be cached, with the holes being punched asynchronously (ajax) on first load and immediately (browser local storage) upon subsequent loads.

I should be able to PR this - just wanted to run it by you before I dove in.

The Form Key block is being cached on the Catalogue View page, so when a user comes to the page their form key is incorrect.

I've updated formkey.phtml to

<?php Mage::registry('diehard')->addIgnoredBlock($this); ?>
<input name="form_key" type="hidden" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>" />

I've also added the following to my themes local.xml

<catalog_category_layered>
	<reference name="formkey">
		<action method="addDefaultIgnored" />
		<action method="setBlockIsDynamic"></action>
	</reference>
</catalog_category_layered>

But the block is still being cached. Please, could you point me in the right direction?

Thanks

I'm just curious if you thought about implementing a method that duplicates the usual functionality in the core to determine the store, e.g.

• use $_GET['___store'] if defined
• if not, use store cookie
• if no query parameter and no cookie, use $_SERVER['MAGE_RUN_CODE']
• otherwise use an empty string, since there is no way to determine the current store at this time

1. Maybe this is a silly question, but there is no information about how to install this extension. Manually help?

2. I have Varnish/Turpentine working great (concurrency 100, requests 2000 - Requests per second 2217.13 #/sec, Time per request 45.103 ms). I used for testing Lesti FPC. Using it standalone Requests per second is around 50 and time per request 2000 ms. This is 45 times bellow Varnish. I changed to use Lest FPC with Varnish/Turpentine. Performance is half than Varnish/Turpentine standalone. In this case I will keep Varnish/Turpentine and that's it. I would like to ask you if I use Cm_Diehard can I get more performance? In my opinion FPC is only for small shops with hundreds visitors per day.

First off, thanks for creating this!

I installed the module via modman and went to evaluate the cache by simply uncommenting a few lines in the module under config/frontend/diehard. I know you advise against this but I just wanted to see the cache in action before I went any further.

        <diehard>
            <!-- Cacheable actions and their lifetimes -->
            <actions>
                <catalog_product_view>86400</catalog_product_view>
            </actions>

            <!-- Dynamic blocks that are ignored for fresh sessions (ignored by default) -->
            <ignored_blocks>
                <!-- Example:
                <catalog.compare.sidebar/>
                -->
               <catalog.compare.sidebar/>
            </ignored_blocks>
        </diehard>

The first thing I noticed is that I get an error if I don't specify at least one ignored block. Is it possible to c ache the entire page without specifying an ignored block?

When I add the ignored block I get this error:

Notice: Undefined offset: 1 in Diehard/code/Model/Backend/Abstract.php on line 129

Thanks Colin!

It turns out having the core/messages block which displays session messages as a dynamic block is pretty tricky.
Maybe you have a clever solution, but at the moment all I'm coming up with are very ugly hacks.

This is an issue for example in the following case:

1. Visitor requests catalog/product/view page (FPC cache hit)
2. Visitor adds product to cart
3. POST request to checkout/cart/add page (not cached).
   The method checkout/session::addSuccess() is called
4. Visitor is redirected to catalog/product/view page (no FPC cache hit since items in cart changed)
5. Page is rendered, core/messges::_prepareLayout() and Mage_Core_Controller_Varien_Action::_initLayoutMessages() clear the session message storage adding the messages to the core/messages block
6. Messages block is rendered and cached.
   But even if output is suppressed, no luck, because:
7. The core/messages block is instantiated again via Cm_Diehard_LoadController::_getResponseObject() loading dynamic blocks
8. No messages are rendered since the messages in the sessions are already unset during the generic rendering of the core/messages block.

The only solution I've found is to persist all messages added to the initial (generic) core/messages block, and re-add them again when the dynamic core/messages block is rendered.
This requires a rewrite of the core/messages block, which I would like to avoid.

I feel like I'm missing a realy elegant solution to this problem.
Do you have a clean solution?

Sometimes fired an issue:

Issue was affected to the file:

app/design/frontend/base/default/template/core/formkey.phtml

PS: file:

app/design/frontend/base/default/template/core/formkey.phtml

Exists, with content:

<input name="form_key" type="hidden" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>" />

With permission:

$ ls -la app/design/frontend/base/default/template/core/formkey.phtml
-rwxrwxr-x. 1 www-data www-data 1083 Feb 14 18:09 app/design/frontend/base/default/template/core/formkey.phtml

Log output:

$ tail -1000 var/report/1438582095995
a:5:{i:0;s:56:"Call to a member function getId() on a non-object (NULL)";i:1;s:2695:"#0 .modman/Cm_Diehard/Mage/Core/Block/Template.php(250): include()
#1 .modman/Cm_Diehard/Mage/Core/Block/Template.php(281): Mage_Core_Block_Template->fetchView()
#2 .modman/Cm_Diehard/Mage/Core/Block/Template.php(295): Mage_Core_Block_Template->renderView()
#3 .modman/Cm_Diehard/Mage/Core/Block/Abstract.php(936): Mage_Core_Block_Template->_toHtml()
#4 app/code/core/Mage/Core/Block/Text/List.php(43): Mage_Core_Block_Abstract->toHtml()
#5 .modman/Cm_Diehard/Mage/Core/Block/Abstract.php(936): Mage_Core_Block_Text_List->_toHtml()
#6 .modman/Cm_Diehard/Mage/Core/Block/Abstract.php(642): Mage_Core_Block_Abstract->toHtml()
#7 .modman/Cm_Diehard/Mage/Core/Block/Abstract.php(586): Mage_Core_Block_Abstract->_getChildHtml()
#8 app/design/frontend/rwd/cdf/template/page/1column.phtml(55): Mage_Core_Block_Abstract->getChildHtml()
#9 .modman/Cm_Diehard/Mage/Core/Block/Template.php(250): include()
#10 .modman/Cm_Diehard/Mage/Core/Block/Template.php(281): Mage_Core_Block_Template->fetchView()
#11 .modman/Cm_Diehard/Mage/Core/Block/Template.php(295): Mage_Core_Block_Template->renderView()
#12 .modman/Cm_Diehard/Mage/Core/Block/Abstract.php(936): Mage_Core_Block_Template->_toHtml()
#13 app/code/core/Mage/Core/Model/Layout.php(555): Mage_Core_Block_Abstract->toHtml()
#14 app/code/core/Mage/Core/Controller/Varien/Action.php(390): Mage_Core_Model_Layout->getOutput()
#15 app/code/local/Act/Locale/controllers/CartController.php(261): Mage_Core_Controller_Varien_Action->renderLayout()
#16 app/code/core/Mage/Core/Controller/Varien/Action.php(418): Act_Locale_CartController->indexAction()
#17 app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch()
#18 app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match()
#19 app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#20 app/Mage.php(684): Mage_Core_Model_App->run()
#21 pub/index.php(268): Mage::run()
#22 {main}";s:3:"url";s:21:"/en_us/checkout/cart/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:5:"en_us";}%

Interesting module. I'm evaluating Diehard cache but getting this error on my CE 1.8.1.0
Serialization of 'Mage_Core_Model_Layout_Element' is not allowed

I have tried disabling cms page optimizations taken from here: http://www.slideshare.net/ivanchepurnyi/making-magento-flying-like-a-rocket-a-set-of-valuable-tips-for-developers - still error out

I have tried to enabled / disable all caches - still error out

Full Error

Serialization of 'Mage_Core_Model_Layout_Element' is not allowed
#0 /var/www/dev.domain.local/releases/2014/app/code/core/Mage/Page/Block/Template/Links.php(191): serialize(Array)
#1 /var/www/dev.domain.local/releases/2014/app/code/community/Mage/Core/Block/Abstract.php(1315): Mage_Page_Block_Template_Links->getCacheKeyInfo()
#2 /var/www/dev.domain.local/releases/2014/app/code/community/Mage/Core/Block/Abstract.php(1468): Mage_Core_Block_Abstract->getCacheKey()
#3 /var/www/dev.domain.local/releases/2014/app/code/community/Mage/Core/Block/Abstract.php(1330): Mage_Core_Block_Abstract->_getTagsCacheKey()
#4 /var/www/dev.domain.local/releases/2014/app/code/core/Mage/Page/Block/Template/Links.php(268): Mage_Core_Block_Abstract->getCacheTags()
#5 /var/www/dev.domain.local/releases/2014/app/code/community/Mage/Core/Block/Abstract.php(1432): Mage_Page_Block_Template_Links->getCacheTags()
#6 /var/www/dev.domain.local/releases/2014/app/code/community/Mage/Core/Block/Abstract.php(937): Mage_Core_Block_Abstract->_saveCache('?

It looks like the diehard/backend_file cache model doesn't exist. Should we comment it out in config.xml for now?
https://github.com/colinmollenhour/Cm_Diehard/blob/master/code/etc/config.xml#L55

Under EE 1.12.0.2, when I have diehard processing the request, I get a notice when Magento tries to instantiate the helper:
https://github.com/colinmollenhour/Cm_Diehard/blob/master/code/Model/Backend/Local.php#L216

Notice: Trying to get property of non-object  in app/code/core/Mage/Core/Model/Config.php on line 1239

I don't know too much about the FPC request processing bootstrapping process, but I'm assuming it tries to load as little as possible before handing control over to the request processor - perhaps it doesn't yet instantiate helpers?

Temporarily adding an isset() around the $config->deprecatedNode seems to resolve it. It looks like this is a core bug that has been addressed in the latest version (CE 1.9):
https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Core/Model/Config.php#L1239

So i got this all to work but the ajax request wasen't updating hte element. I found that this was to do with the : in dh:_someelementname

So i updated Mage/Core/Block/Abstract.php, line 1260 to:

        return '#diehard_'.preg_replace('/[^a-zA-Z0-9]+/', '_', $this->getNameInLayout());

Works a treat now.

I just tried enabling early_flush by adding

<early_flush>1</early_flush>

to my app/etc/local.xml

I'm seeing an error though it looks like:

Notice: ob_flush(): failed to flush buffer. No buffer to flush  in .modman/diehard/code/Model/Backend/Local.php on line 198

#0 [internal function]: mageCoreErrorHandler(8, 'ob_flush(): fai...', '...', 198, Array)
#1 .modman/diehard/code/Model/Backend/Local.php(198): ob_flush()
#2 app/code/core/Mage/Core/Model/Cache.php(663): Cm_Diehard_Model_Backend_Local->extractContent(false)
#3 app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Model_Cache->processRequest()
#4 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#5 index.php(90): Mage::run('', 'store')
#6 {main}

I haven't yet dug into this at all to see what might be causing it - just wanted to post this up quickly while I was in there.

As an alternative to Ajax and ESI, the "BigPipe" method could be implemented on top of Server-side Javascript injection method. Basically just flush the cached portion of the page before rendering the dynamic portion. Duh! It is not really BigPipe since it is only two stages, but perhaps with additional work each dynamic block could be flushed separately.

Thank you for doing this!

We have used ezoom (ezapps) and Brim. But this is cool. Is it still beta would you think? of community production worthy?

ps. Did oyu see this? https://github.com/liquid-i/Magento_Cache_Warm_UP Stumled on this code when looking for a script that re-uses the sitemap generation code. Would be great to include something like this that could be run by a cron job say every night or week etc

Again. Many thanks for your efforts.

Colin, finally getting around to diving in a little deeper to this. This module is so incredible - it's blowing my mind.

Hey would you be okay with me submitting a quick PR to tighten up some white space issues? Ex: two spaces instead of four here:
https://github.com/colinmollenhour/Cm_Diehard/blob/master/code/Model/Observer.php#L68