Matrix Cache - Getting it Right

(Scott Hall) #21

[quote]
I have to correct a bit about above list:

Following Design Areas can't cached ( even you specify cache = yes, it won't work anyway):



design_area_login_form.inc

design_area_menu_type.inc

design_area_body.inc

design_area_exit.inc

design_area_show_if.inc



Rest of them can be cached at selection.

Actually labs is working on a series of performance tests. One of them will be comparing cache on/off for various design areas. Hopefully, it will help implementer to decide which design areas they really should turn on caching.

[/quote]



Thanks Ed,



I'll add to that a little bit…



The LOGIN design area can hurt your feelings. If you have solid caching enabled at multiple levels you will most likely have clients say that they see strange results when using their login boxes, why? Stale browser cache is the likely candidate. Often (if the client is OK with a JS solution) we will use an AJAX solution to login e.g. dynamically talk to a standard page that has a custom design applied, that only has login design area inside it, or alternatively creative AJAX use of account manager asset. Just make sure you bust cache when talking to the assets.



The EXIT design area was a gift from the dev gods so Anthony and I could get EES working as expected, unless someone comes up with other creative ways to use/bend this then you don't need to worry about it unless your trying to get EES working.

(Robin Shi) #22

Cache is my old friend from Matrix family, we had a long story…


Okay, first, the header of last-Modified should be turned off, it comes from the last updated date of the asset whose URL is hit. Think about how painful it is when the asset has nested asset listing in the content or from the paintlayout/design.



Secondly, the cache in the design settings. Whether it’s on or off, it still depending on the nested content’s cache. Say you nest an asset listing in the design, turn the cache on. But asset listing asset type has not cached, this still doesn’t help.



Lastly I’d ask for clarification about Nic’s reposting, http://forums.squizsuite.net/index.php?showtopic=8044.

In line 24, [quote]You would set Matrix cache time to say 6 hours, but set the system to send headers to 30 minutes. This allows you to update content in 30 minutes windows without having the penalty of rebuilding pages that were not updated. Squid will come back to Matrix for pages every 30 minutes, but this won’t matter as the Matrix cache will have them. [/quote]

I am not sure about how the setting for the browser cache works but in my opinion, the browser cache is timed in the user’s browser, when it expires the Squid requests to gain the copy from Matrix cache. For instance, say, the browser cache set to 3600 (one hour). The browser hits the page on 1.00pm, the header recorded the expiry time is 2.00pm. On 2.01pm the browser opens the page and Squid gains the new copy from Matrix cache (it’s slightly slower than before the cache expires). In case here is another user visits the same page on 1.01pm, the expiry time will be 2.01pm, so Squid gains the new copy from Matrix again if the page is revisited on 2.02pm by the second user.

Happy to discuss about this.



Robin



Edit: wording has been changed to make it clear

(Greg Sherwood) #23

[quote]
Okay, first, the header of last-Modified should be turned off, it comes from the last updated date of the asset whose URL is hit. Think about how painful it is when the asset has nested asset listing in the content or from the paintlayout/design.

[/quote]



Actually, it returns the most recent modified date of all the assets loaded while printing the page. This includes assets in the designs and paint layout. Once it has the list of loaded assets, it queries the DB to get that date. If caching is stopping an asset from being loaded at all (maybe a design area) then that asset's modified date will not be included as you're looking at an old version of it anyway.

(Robin Shi) #24

[quote]
Actually, it returns the most recent modified date of all the assets loaded while printing the page. This includes assets in the designs and paint layout. Once it has the list of loaded assets, it queries the DB to get that date. If caching is stopping an asset from being loaded at all (maybe a design area) then that asset's modified date will not be included as you're looking at an old version of it anyway.

[/quote]

Thanks Greg for the clarification. Is the last update date of the listed items from asset listing included?

(Greg Sherwood) #25

[quote]
Thanks Greg for the clarification. Is the last update date of the listed items from asset listing included?

[/quote]



There may be a case where listings don't have to load the assets they are listing, but I can't think of one. So yes, they would be included.

(Robin Shi) #26

[quote]
There may be a case where listings don't have to load the assets they are listing, but I can't think of one. So yes, they would be included.

[/quote]

From my experience, _nocache and hard refresh let visitor see updated listed items, but refresh and re-visit don't. We had the issue until we removed the last-modified header.

(Dan Simmons) #27

Yes, I've had problems with IE6 and using the "Last-Modified" header (where IE6 would load from cache even though the cache expiry time had elapsed). For this reason I always turn it off. It makes caching more predictable that way anyway, as there is only a single directive sent to the browser so it doesn't get confused when determining whether an object is fresh or not.

(Scott Hall) #28

I've always left last mod off in the sys config settings becuase of inconsistent browser behaviour as per Dan's comments. Just having 'send cache headers'=yes without last mod on has worked perfectly for me to date.

(Scott Hall) #29

Remember to handle assets/URLs that need to be processed my matrix every time carefully…


Example:



Matrix cache and cacheable headers are on, so there is asset level cache for the URL and there is browser level cache for the URL. If proxy exists there will also be proxy cache for the URL. Thats three levels of cache that need to be considered if you are trying to dynamically chat with matrix directly.



I have a form nested into a standard page and for some reason every submit won't send an email nor will it create a new submission log.



Woops, I forgot… I'm not logged in and the browser cant talk directly with matrix to process the post request, it's hitting cache at some level.



Solution:


  1. Create cache manager overrides for the form itself and the page that has it nested. Set caching = no and for good measure set default and browser expiry to 0.



    Or alternatively…


  2. Look for a client side web dev solution like busting the cache by appending the form action url with /_nocache and a random get var so it will bypass cache with each submit.





    Anyone else have any lurgies they would like to mention, like dealing with asset builders or account managers that are available to the public?
(Robin Shi) #30

[quote]
Remember to handle assets/URLs that need to be processed my matrix every time carefully…



Example:



Matrix cache and cacheable headers are on, so there is asset level cache for the URL and there is browser level cache for the URL. If proxy exists there will also be proxy cache for the URL. Thats three levels of cache that need to be considered if you are trying to dynamically chat with matrix directly.



I have a form nested into a standard page and for some reason every submit won't send an email nor will it create a new submission log.



Woops, I forgot… I'm not logged in and the browser cant talk directly with matrix to process the post request, it's hitting cache at some level.



Solution:


  1. Create cache manager overrides for the form itself and the page that has it nested. Set caching = no and for good measure set default and browser expiry to 0.



    Or alternatively…


  2. Look for a client side web dev solution like busting the cache by appending the form action url with /_nocache and a random get var so it will bypass cache with each submit.





    Anyone else have any lurgies they would like to mention, like dealing with asset builders or account managers that are available to the public?

    [/quote]

    Don't nest form in a standard page, the workaround sounds risky if the page has high hits.

    http://www.acu.edu.au/apply_and_enrol/information_for/future_undergraduate_students/changing_your_preference/

    I used Nic's Matrix Plugin (ajax like hack).

    Robin
(Nic Hubbard) #31

[quote]
I used Nic's Matrix Plugin (ajax like hack).

[/quote]



Ha! That plugin is so old. I would recommend now using the JS API.

(Robin Shi) #32

Yeah, I hope I had time to set up web services.

(Tbaatar) #33

There seems to be a caching problem when you nest a Custom Form and try to send it fails. But if if you turn cache off then the form sends.


I tested this on Matrix v3.28.3 and v4.0.3, and it both fails to send or give error message.



Any pointer or help much appreciated.





Thanks.

(Nic Hubbard) #34

[quote]
There seems to be a caching problem when you nest a Custom Form and try to send it fails. But if if you turn cache off then the form sends.



I tested this on Matrix v3.28.3 and v4.0.3, and it both fails to send or give error message.



[/quote]



Yeah, you can't nest custom forms, because they get cached and won't work when cached.

(Duncan Robertson) #35

You used to be able to right? Or am I imagining this?

(Nic Hubbard) #36

[quote]
You used to be able to right? Or am I imagining this?

[/quote]



You have never been able to. The two work arounds to this are to use ajax to point to a "hidden" custom form at another URL, and to use a nest design area in your parse file, turn off caching for that area, then nest the custom form.



Check out this thread: http://forums.squizsuite.net/index.php?showtopic=7644&view=&hl=nest%20custom%20form&fromsearch=1



Edit: Another option is to use an iframe for your form, but that is ugly.

(Benjamin Pearson) #37

[quote]
You have never been able to. The two work arounds to this are to use ajax to point to a "hidden" custom form at another URL, and to use a nest design area in your parse file, turn off caching for that area, then nest the custom form.



Check out this thread: http://forums.squizsuite.net/index.php?showtopic=7644&view=&hl=nest%20custom%20form&fromsearch=1



Edit: Another option is to use an iframe for your form, but that is ugly.

[/quote]



Or you nest the page in the form itself

(Tbaatar) #38

Thanks for the feedback.


I have 2 custom form that needs to be displayed on a single page, so I'm using standard page to nest both the forms. Instead can I nest the custom form inside another custom form to overcome this cache issue?







edit: tried this today and it fails to work for the 2nd form in the hierarchy.

(Rhaggith) #39

Awesomely awesome thread, thanks Scott (and Squiz, and everyone)!


I've got two forms nested into a paintlayout and these forms appear (for the time being) to work, perhaps you should consider using a paintlayout instead of nesting into a standard page, tbaatar?



BUT, would this essentially screw caching for all of the pages this paintlayout is applied to, as the page would need to grab a dynamic response depending on the form response? Is that crazy talk?

(Nic Hubbard) #40

[quote]
Thanks for the feedback.



I have 2 custom form that needs to be displayed on a single page, so I'm using standard page to nest both the forms. Instead can I nest the custom form inside another custom form to overcome this cache issue?







edit: tried this today and it fails to work for the 2nd form in the hierarchy.

[/quote]



Yeah, this won't work, because the form asset puts <form> tag around the page, so when you nested another one in, you have nested form tags, which, will break one of them.



The paint layout suggestion is probably your best bet.