ESI Blocks in LiteMage config.xml

[LSUser12]

The configuration documents (https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:cache:litemage:customization:configuration-file) mention configuring purge events (using the purge_events element).

Certain dispatched events in Magento seem to work with Litemage in this fashion as seen in the debug log:

2015-08-21T22:21:42+00:00 DEBUG (7): sales_quote_save_after
2015-08-21T22:21:42+00:00 DEBUG (7): LiteMage [68.230.120.153:54679:89837200] Purge events sales_quote_save_after tags: E.cart, E.dynamicnav, E.toplinks, E.reorder
2015-08-21T22:21:42+00:00 DEBUG (7): LiteMage [68.230.120.153:54679:89837200] SetPurgeHeader: private, tag=E.cart,tag=E.dynamicnav,tag=E.toplinks,tag=E.reorder (triggered by event sales_quote_save_after)

... however, is there some sort of listing showing which dispatched events can be used as purge events?

Second question:

Is there some way to ensure that a block is never cached using app/code/community/Litespeed/Litemage/etc/config.xml ?

 

[Lauren]

... however, is there some sort of listing showing which dispatched events can be used as purge events?

Current config.xml covers the default installation. So you have special extensions that create their own events, you may need to modify the config. There will be no such list of all purge events.

If a block can never be cached, then probably that page is not cacheable, every request will have to go to backend and invoke PHP, initialize Magento framework. If a block can be privately cached, then you can punch a hole there, and define purge events to update it. I need to know more details about your use cases.

 

[LSUser12]

Lauren,

> I need to know more details about your use cases.

This is in the context of providing support to customers who might be interested in using LiteMage. If we want to offer this to our customers from the web host perspective, we need to educate ourselves on how to support those customers.

Honestly I feel like you guys really shot yourselves in the foot by making your extension closed source behind IonCube. You guys already own/license the web server which requires this, was it really advantageous to prevent developers from better understanding your caching solution? I've got to think that alone is reason to use Turpentine/Varnish over LiteMage ;-/ . I was just preparing to spend some time getting ready to dive into how this works since we're suggesting it to people, but that's a hard sell seeing you've closed sourced this whole project.

> There will be no such list of all purge events.

And we have no way of figuring it out either. Fun

 

[Lauren]

If you want to offer LiteMage to your client, we can initially work closely with you to help trouble shoot all issues.

We're gradually making more content in our wiki. The idea of caching is the contents are served from web server directly, do not go to PHP and Magento backend. PHP based caching avoid invoking Magento framework, which is quite heavy. LiteMage or Varnish based solution will avoid going to PHP. But LiteMage can use combined requests and other ESI functions that Varnish does not support. and it also supports HTTPS and HTTP/2, is better option than varnish based solution. Back to your original question, if a block can never be cached, that means every request it will need to go to magento and initialize the framework. This will defeat the purpose of caching. If you enable "Log recently viewed", it will work that way. For every product page viewed, it will send a request to backend and log it in the database, which is big difference than you disable it. If you have a real use case, we can add that support. Right now a punch hole block is either public cached or privately cached. We can define a "no_cache" block, it will work like "log recently viewed", basically other parts will be assembled from cache and this block will be retrieved from backend.

If you look at config file and our wiki, you can see that LiteMage is tag based, you can associate blocks (based on either block name or block type) with a tag, and each tag will be purged by events. The event listener will simply add a purge header for that tag, and web server will purge everything that associated with that tag. You can define your own events in your extension. So there's no fixed list of events. If you turn on debug log, you will see which request is not cacheable, it also print out the route (action name). So if that request is cacheable, you can add to user defined cacehable routes.

We can work closely with you, and update our code as needed. Currently for AJAX based navigation, if it is ajax get request, it will be cached, it does not cache POST request, including AJAX POST. We'll add support for that later. You can email us directly.

Thanks,
Lauren

 

[LSUser12]

> We can define a "no_cache" block, it will work like "log recently viewed", basically other parts will be assembled from cache and this block will be retrieved from backend.

That sounds good. I frequently run into poorly coded shops where one particular block, that CAN be cached, is the vast majority of the page load time. If all we wind up doing is hitting the back-end for some relatively fast loading non-cacheable block, that certainly doesn't defeat the purpose of having a caching solution in the first place.

As an example, there are some layouts I see where the navigation takes a tremendous amount of time to load (due to poor coding). Not offering the service of rewriting their navigation, a happy compromise with our customers is to cache that one block (in Magento). If LiteMage cached that slow block and many other blocks, except for one dynamic one we and the customer doesn't want to deal with... that would improve page load time.

Really all that I think is needed for LiteMage to be easily usable is simply to allow us to specify a TTL per block rule in config.xml. You have a setting called "Default Private Cache TTL", so it sort of implies that there's some way to specify a block cache's TTL (otherwise it's not a default setting, it's just the setting). If you had that, then someone could just set the TTL to zero and resolve the issue of not being able to prevent a block from being cached.

 

[Lauren]

Sorry for reply late. We do have <ttl> option for each tag, where user can define different ttl. I don't see much use of it, so did not list in our wiki. For no-cache block, I prefer to <access> is <nocache>, as it is not public or private cache, it is simply no cache, and no purge event needed. I don't see an urgent need for this, until I see a real use case. I can include this feature in next build.

If you are trying LiteMage on your client site and have problems, feel free to contact us. We'll get it resolved. If you ever submit bugs to us before, you will know how fast we can turn around with bug fixes.

Lauren