提升place order 后的速度

http://www.alphaquad.co.uk/blog/2013/01/is-your-magento-checkout-slow

Has your Magento store experienced any significant slowdowns during the checkout process, more specifically when customers place an order (during the final stage)? If so read on to find out more on the problem, the reasoning behind it and a solution to this common occurrence!

Magento’s extreme scalability as an ecommerce platform allows store owners to create multiple stores using a single software installation, being able to quickly add thousands of products and categories. To speed up the frontend due to so much going on, Magento adopts an elaborate caching mechanism, storing common and reusable information including page layouts, blocks and collection objects in cache storage. Consequently the more products, categories, stores and themes your installation has, the larger the cache will become over time. By default cached files are stored in the /var/cache folder of your setup. Each cache item when created is given a ‘tag’, allowing Magento to categorise the cache (such as layout, blocks) and when need be search through and clean specific elements dependant on their tag.

It seems ironic that caching could be the root cause to this slow down of your Magento system, but let me explain briefly why this is so...

The problem

This may seem a little off topic, but one feature included with Magento is RSS functionality, which in addition to many other features, provides:

• customers the ability to receive live updates on their order
• a low stock feed (password protected), allowing store owners to become aware of products running low in stock

When completing the checkout procedure in Magento, once an order is placed, the “sales_order_item_save_after” observer event is invoked. Search your code base you’ll find that there are two observer events intercepting this event in /app/code/core/Mage/Rss/etc/config.xml:

Here lies the root cause to our problem with both of these observer methods evoking a cache cleaning routine. If we take a look at the first example, navigating to the observer referenced Mage_Rss_Model_Observer (/app/code/core/Mage/Rss/Model/Observer.php) you’ll see:

Here we can see a cache clean routine is being invoked based on a given tag. If you look at the model Mage_Rss_Block_Catalog_NotifyStock referenced in the call, you’ll see a cache tag “block_html_rss_catalog_notifystock” having been defined.

This prompts Magento to search its cache storage for any blocks with a tag of this value. It’s worth noting although there could be several instances of cache content (standard block caching for example) with this tag, there is only ever one cache file with a tag of BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK (take our word for it).

With some cache file searching you can find the appropriate cache references:

mage--7/mage---internal-metadatas---f35_RSS_CATALOG_NOTIFYSTOCK

The metadatas file is a reference to the cache content itself. Here we can see it defines the cache content of having a cache tag of “block_html_rss_catalog_notifystock” as we noted above, in addition to the block expiry time and another cache tag of “Mage” (a tag used to flush the entire Magento cache from the admin panel).

mage--7/mage---f35_RSS_CATALOG_NOTIFYSTOCK

Next if we find the content of the referenced cache element (above) you’ll see the output is the same XML you’d see if you were to view the low stock RSS feed from the admin panel (Catalog > Manage Products > click “Notify Low Stock RSS”) or by visiting http://example.com/index.php/rss/catalog/notifystock/).

Each time you view the notify stock feed its content is cached, therefore as customers are ordering products from your store, this content needs to be continuously cleared to provide accurate results to the store owner.

The reason for the slowdown should now be evident. Each time orders are placed Magento needs to search your entire cache storage to find this cached content. The smaller your cache the quicker it’ll be at doing this.

Even if you don’t have the RSS feed module enabled (System > Configuration > Catalog > RSS Feeds) this routine will still continue to run (shouldn’t this have been checked before these observer methods are run? - BUG).

The solution

To combat the problem we’ve written a simple module* that disables these two RSS observer methods.Simply download and extract our simple module*, keeping the same folder structure given. You’ll need to flush the configuration cache for this to take effect (System > Cache Management > tick ‘Configuration’ and click ‘Refresh’).

An alternative approach we found  to work(without having to disable these observer events) was to use APC caching, replacing the standard file based cache system. Magento offers support for industry known caching systems out of the box, namely APC and memcached. Another advantage of using APC was being able to cache PHP files and speed up the overall speed of the website. However, more on this in a later post and the approach we took to achieve this.

If you’d like more information on this topic, or to discuss how we can help with your Magento store in general, get in touch with James and Matt today.