Magento caching, APC, eAccelerator Memcached, files, sqlite, Vanish, what’s the … happen?
Magento is slow! It’s how start most of the article about Magento cache optimization. Yes, Magento is slow and this because of the way the code is written, extreme object oriented. Stackoverflow say “It is written in an Enterprise Java idiom” and there are right. Anyway, we can’t change anything about it and in one side that let us lot of flexibility.
So, Magento IS SLOW! And what’s can we do? There is many thing to do, many, many. But the most important one is to work around the cache. I am searching for a cache solution and found so much different stuff like APC, eAccelerator, memcached, tmpfs, varnich, lighthttpd, nginx and so on… I will try to explain the different possibilities if found while my research and finished by the one I will implement.
Let’s start by the easiest thing to do by using a PHP accelerator. This is just a PHP extension to install that will take care to cache the code compiled in shared memory without to do it for each request. But there is many of them http://en.wikipedia.org/wiki/List_of_PHP_accelerators . From all of them, 2 comes out: eAccelerator, it is very popular because it is very fast and APC a bit slower but it will be integrated by default in PHP. Personally, I will choose APC but you can make your own choice.
Besides a opcode cache, this 2 extension also provide a user cache for storing application data. That’s mean you can store some variable in shared memory. Each of this variable will be identify by a unique key you will attribute.
And what’s about memcached?
Memcached is made to store data in shared memory and to be able to distribute it on different server. This solution is a bit slower than APC or eAccelerator but perfect if you are doing clustring. In case you are not on a trusted networks, you can secure it with SASL authentification (I was also thinking about SSH tunneling). http://code.google.com/p/memcached/wiki/SASLAuthProtocol
Slow backend, fast backend, wtf?
The fast backend will be a small part of memory very fast that will be checked in first for data. If this data is not found there, then it will be checked in the slow backend, bigger part of memory but slower. Magento allow this 2 type of level. We can imagine about a configuration like:
fast: APC, slow: file
fast: APC, slow: memcache
fast: memcache, slow: database
You should read this article http://www.fabrizio-branca.de/magento-zend-frameworks-twolevels-cache-backend-mess.html from Fabrizio Branca.
Another great article http://www.byte.nl/blog/2011/06/16/speeding-up-magento-the-burden-of-two-level-cache/
So if you have enough shared memory, may be you should just use fast backend, like APC.
Apache kill my Ram!! What’s about using lighthttpd or nginx?
Now you are using cache variable in memory, you will need as much as possible memory available. Also if you are using memcached on a different server apache still using so much memory. Why not using something else, with high performance and low memory usage, like lighthttpd or nginx. Lighthttpd is more known but nginx seem to be faster and more stable. Also it’s easy to configure and it supports load balancing.
What’s about Varnish?
Varnish is an HTTP accelerator. It will cache the html page generated and retrieve them directly without to call the Magento framework. This is a very good concept because Magento is very slow to initialize. Also with all the previous optimization it’s still difficult to have page loading under 0.5sec. The only problem is that your shop has some dynamic data like the cart and so on. The is different solution for it like AJAX or ESI (Edge Side Includes). For more information you should read the following article:
From my point of view, I think this solution is too complicated and not enough complete from the way to manage the dynamic part of the page.
My concept, youhou
My concept is very simple. I will only cache the catalog. Every time the catalog change, I will update all the page concerned. Each page will be save in a phtml file. In all this page, there are multiple part that are specific to the user. We will simply save this part of the page inside the session. For example when the user update his cart, an event is dispatched, I catch this event and then update my session. In the phtml, I put some php to include this specific user part. Then, if the cache exist, you use it else you call Magento. Easy, no?
January 26, 2012 Thursday at 2:50 pm