You need to understand the clear distinction between these two products to understand how to use them.
- APC is both an OPCode Cache and Fast Backend
- Memcache is just a Fast Backend
Using APC as an OPCode Cache
Simply install the module on your server
pecl install apc
And enable it in your php.ini
echo "extension=apc.so" >> /usr/lib/local/php.ini (RedHat/Centos)
echo "extension=apc.so" >> /etc/php5/conf.d/20apc.ini (Debian)
You then enable and fine-tune the runtime configuration to suit, eg.
apc.enabled
apc.shm_segments
apc.shm_size
apc.optimization
apc.num_files_hint
apc.user_entries_hint
apc.ttl
apc.user_ttl
...
Then restart PHP/Apache
/etc/init.d/httpd restart (RedHat/Centos)
/etc/init.d/apache2 restart (Debian)
After that, there is nothing else to do. Confirm APC is enabled with a quick phpinfo()
- but otherwise, at this point, the OPCode cache portion of APC is active.
Nothing needs to be configured on Magento's side.
Using APC as a Fast Backend
You need to add the following to your ./app/etc/local.xml
<global>
...
<cache>
<backend>apc</backend>
<prefix>mystore_</prefix>
</cache>
...
</global>
Then flush your existing store caches. To verify it is working, load a page in the front-end and the ./var/cache
directory should remain empty.
Using Memcache as a Fast Backend
You'll need to install Memcache as a PHP extension, and install the respective Memcache Daemon (Memcached) on your server.
pecl install memcache
And enable it in your php.ini
echo "extension=memcache.so" >> /usr/lib/local/php.ini (RedHat/Centos)
echo "extension=memcache.so" >> /etc/php5/conf.d/20memcache.ini (Debian)
/etc/init.d/httpd restart (RedHat/Centos)
/etc/init.d/apache2 restart (Debian)
Then install Memcached on the server. For RH/Centos, adjust the URL to suit your release version and CPU architecture.
rpm -Uhv http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
yum --enablerepo=rpmforge install memcached
apt-get install memcached (Debian)
Then modify Magento to use Memcache as a fast backend, change the socket path to a TCP/IP connection to suit.
<cache>
<slow_backend>database</slow_backend>
<fast_backend>memcached</fast_backend>
<fast_backend_options>
<servers>
<server>
<host>unix:///tmp/memcached.sock</host>
<port>0</port>
<persistent>0</persistent>
</server>
</servers>
</fast_backend_options>
<backend>memcached</backend>
<memcached>
<servers>
<server>
<host>unix:///tmp/memcached.sock</host>
<port>0</port>
<persistent>0</persistent>
</server>
</servers>
</cache>
The caveats of Memcache and tagging - what is it storing
Memcache only supports a single level of key-value relationships, so it cannot store the Magento cache tags (that are used to flush cache data independently). As a result, you either need to specify a slow_backend
to maintain the cache content tag relationship, or don't define one at all.
If you define a slow_backend
, you run the risk of the cache tags growing so large that performance is negated; there is also the inherent problem that you cannot scale across multiple servers if each server is maintaining their own cache tags.
So when using Memcache, the better approach (with the caveat you cannot flush caches independently), is to not bother using the slow_backend
.
In which case, we suggest removing <slow_backend>database</slow_backend>
and replacing it with:
<slow_backend>Memcached</slow_backend>
<slow_backend_options>
<servers>
<server>
<host>unix:///tmp/memcached.sock</host>
<port>0</port>
<persistent>0</persistent>
</server>
</servers>
</slow_backend_options>
This will break/disable the 2nd level of caching (and prevent tag storage), but still allow the performance of Memcache.
Which to use
If its a single server deployment - there's no harm just using APC for everything.
If its a distributed set-up - then you'll need to use Memcache as the fast backend (so that all machines can access the common store).
More concerning is that if your hosting provider can't tell you the right set up to use, you are certainly with the wrong host.
Attributions: sonassi.com, php.net, repoforge.org
Best Answer
You don't have nearly enough RAM
You do not have nearly enough RAM for the amount of products you have. As a rule of thumb, we recommend at least 2-4GB RAM per logical core.
If you map out your possible memory usage:
max_memory
of ~768MB = 24GBlzf
compressed - will still consume about 6GB of RAMSo the total so far is 70GB of committed RAM - we've not even mentioned the OS etc.
Your hardware is dreadfully underspecified. I would suggest reading over this Magento server set up article for a bit of a feeler on how to progress.
Memcached doesn't support cache tags
If you're using Memcached (not a problem, its very high performance), then you are either storing cache tags or not. If you don't have a
slow_backend
defined - then you're not storing tags, which basically means your cache cannot discriminate between any of the different cache types - so you won't be able to flush them independently.Have a read over this, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/
We would strongly suggest switching over to Redis. It has its quirks and does need significant fine-tuning for larger stores. But as a whole will perform slightly better than Memcached with the real benefit of cache-tag support.
404's and FPC
FPC has a real problem, in-fact, all caching engines have a problem with 404s. The reason being, any old URLs still being crawled or linked to will land on a page that has to iterate through the entire
core_url_rewrite
table, try and find a match against all defined routers and namespaces before finally giving up and loading a 404.Then caching a resource which has no value and will consume space in your cache storage. You'll probably find a huge proportion of your Memcached storage is actually being eaten by 404 content.
With large catalogues (240k products), you're certainly going to have your fair share of product turnover, and thus, changes in URLs and subsequently, many 404's.
FPC Invalidate vs. Clean
At the moment - and by default - FPC's behaviour is to clean the cache on changes, rather than merely invalidate the cache entry. We wrote an extension to alter this behaviour for an EE store to do exactly what you required.
Here's a quick patch to give you an idea of how to solve your issue.
Don't run a crawler
If you've got decent enough footfall - we don't advise running the crawl tool, it generates unnecessary load. People/bots/crawlers browsing the site should keep the cache primed.
But to answer your question, if you look in the configuration file mentioned above - you see the cron schedule that has been defined for the crawl browsing window.
If you can afford stale content
And ultimately, if you have enough RAM. You could well benefit from increasing the TTL of content stored in FPC - to keep your cached data alive for longer.
In the
<full_page_cache>
tag in your./app/etc/local.xml
just defineThe lifetime is defined in seconds. You need to strike a balance between content freshness, performance and the amount of storage space you actually have available.
Why are you using a 3rd party caching extension with EE
You're paying a premium for FPC - which pains me to say, is very good. So why are you running 3rd party alternatives over the top. Remove it.
Put it this way. If your car was running badly - would you just add another engine in the boot to compensate; or just fix the engine already in there?