- June 2019
- September 2018
- May 2018
- December 2017
- April 2017
- June 2016
- February 2016
- November 2015
- January 2015
- August 2014
- July 2014
- May 2014
- March 2014
- February 2014
- January 2014
- November 2013
- August 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- December 2012
- November 2012
- September 2012
- June 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- September 2011
- July 2011
- June 2011
- May 2011
- March 2011
- January 2011
- October 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- September 2009
- July 2009
- June 2009
- May 2009
- March 2009
- September 2008
- April 2008
- December 2007
- June 2007
- June 2005
- September 2004
- May 2002
- October 2001
- August 2001
2013-11-13: Making use of Magento's cache
Popular open source e-commerce solution Magento can be quite slow, but there are ways of improving its performance. Caching is one very effective way and Magento supports various caching backends out of the box, including Memcached. If you write your own Magento extensions, be they plugins or templates, you might benefit from using the cache for things that might otherwise tie up a lot of resources to recompute. This is quite easy to do, but information on caching is surprisingly rare. So how do you do it?
Using a cache is quite simple. First, you check whether the data you need is already in the cache. If it is, then you can simply use it and be done. If not, you will need to do whatever you need to do to compute or construct that data. Then, place it in the cache where it will remain for later use. Bear in mind that in order to be safe, the data should be stored in string form and needs to be serialised upon placement in the cache, deserialised upon retrieval. Here's some sample code, making use of Magento's built-in cache, regardless of the configured backend:
<?php
//Get a handle to interface with Magento's caching backend
$cache = Mage::app ()->getCacheInstance ();
//Try to load the item from the cache
$temp = $cache->load ('item-identifier');
if ($temp !== false)
{
//The item was loaded from the cache (as a string), so restore the actual item object
$item = unserialize ($temp);
} else {
//The item was not in the cache so, do whatever it is you need to do to build it here:
$item = /* insert loads of stuff here */;
//Item has been rebuilt, so store a serialized version of it in the cache
$cache->save (serialize ($item), 'item-identifier', array (), 3600);
}
?>
The string 'item-identifier' is used as a key to store/retrieve your cached data; think of it as a name for the slot you're using in the cache. Choose a unique on for each thing you're placing in the cache. The empty array() can be used to specify a set of tags, but since not every caching backend supports tags, I've left this empty. And finally, the 3600 is the number of seconds to keep the item cache. After 1 hour, the cached data is marked expired. Note, however, that the caching backend may chose to evict the data from the cache much earlier than that, such as when it runs out of memory.
There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton
Be sensible about chosing a time during which your data should be cached. Make your choice based on how often your data is accessed and how dynamic it is. If your timeout is too short, you lose the benefits of caching and you end up recalculating every time the data is accessed. If your timeout is too long and your data too dynamic, you may get stale data.
Comments
No comments, yet...
Post a comment