Comments on: APC or Memcached http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/ Everything about MySQL Performance Fri, 04 Jul 2008 14:15:41 +0000 http://wordpress.org/?v=2.5.1 By: Johnny http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-315424 Johnny Fri, 20 Jun 2008 13:00:55 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-315424 I just laugh when I read this, I developed my own framework focused on advanced cache control methods and functionality. I use both APC and Memcached combined. I use each where they will be most efficiently effective. One is not really better than the other, they are designed to do different things. If you want to create something amazing, use them in tandem. I just laugh when I read this, I developed my own framework focused on advanced cache control methods and functionality. I use both APC and Memcached combined. I use each where they will be most efficiently effective. One is not really better than the other, they are designed to do different things. If you want to create something amazing, use them in tandem.

]]> By: Stephen Johnston http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-298190 Stephen Johnston Tue, 13 May 2008 00:17:42 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-298190 Memecached has a 1 megabyte item limit, so your 50mb objects are out of luck with memcached anyway. Memecached has a 1 megabyte item limit, so your 50mb objects are out of luck with memcached anyway.

]]> By: perlchild http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-195186 perlchild Fri, 16 Nov 2007 17:21:14 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-195186 50MB? Some of my developers have larger objects than that... (external xml imports, so no way to shrink them either) 50MB?
Some of my developers have larger objects than that…
(external xml imports, so no way to shrink them either)

]]> By: peter http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-179314 peter Sat, 20 Oct 2007 15:41:54 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-179314 Enzo, Even if you have multipe web servers there are some things which you can cache in local APC - yes they will be copied on all of your web nodes but if their total size is say 50MB why would you care ? Cache invalidation is another problem which can be done with TTL and versions even in such envinronment. Enzo,

Even if you have multipe web servers there are some things which you can cache in local APC - yes they will be copied on all of your web nodes but if their total size is say 50MB why would you care ?

Cache invalidation is another problem which can be done with TTL and versions even in such envinronment.

]]> By: Enzo http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-179071 Enzo Fri, 19 Oct 2007 20:43:22 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-179071 If you have multiple webservers, then local APC caches aren't going to cut it. Request will be load balanced across various servers and so what was cached on one server will no be in the cache on the other server so you'll end up w/ more cache misses. Memcached solves this problem since it is distributed. If you have multiple webservers, then local APC caches aren’t going to cut it. Request will be load balanced across various servers and so what was cached on one server will no be in the cache on the other server so you’ll end up w/ more cache misses.

Memcached solves this problem since it is distributed.

]]> By: Memcached: When You Absolutely Positively Have to Get It To Scale the Next Day « SmoothSpan Blog http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-171288 Memcached: When You Absolutely Positively Have to Get It To Scale the Next Day « SmoothSpan Blog Sun, 23 Sep 2007 21:25:14 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-171288 [...] Memcached is slower than local caches such as APC cache since it is distributed.  However, it has the potential to store a lot more objects since it can harness many machines.  Consider whether your application benefits from a really big cache, or whether some of the objects aren’t better off with smaller, higher performance, local caches. [...] [...] Memcached is slower than local caches such as APC cache since it is distributed.  However, it has the potential to store a lot more objects since it can harness many machines.  Consider whether your application benefits from a really big cache, or whether some of the objects aren’t better off with smaller, higher performance, local caches. [...]

]]> By: peter http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-4730 peter Tue, 03 Oct 2006 13:30:26 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-4730 Robin, It might be hard to convince people to use anything. Especially if this is technology which they are not familiar with. In the case you're speaking about I would probably use small local APC cache plus distributed memcached, running on the same set of boxes. Memcached is fast but even run locally it is much slower than APC. For most applications you would not notice too much differnece to be honest as even 20.000 of lookups per second means your pages will be lightning fast even with 100 cache lookups per cache :) Robin,

It might be hard to convince people to use anything. Especially if this is technology which they are not familiar with.

In the case you’re speaking about I would probably use small local APC cache plus distributed memcached, running on the same set of boxes. Memcached is fast but even run locally it is much slower than APC.

For most applications you would not notice too much differnece to be honest as even 20.000 of lookups per second means your pages will be lightning fast even with 100 cache lookups per cache :)

]]> By: Robin http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-4729 Robin Tue, 03 Oct 2006 12:58:55 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-4729 Peter, that's correct. However, for some reason, some people don't feel like using Memcached (took me 3 months to convince my manager). If you want a local cache, you could run a local instance of memcached as well and connect to it using a local socket. Personally I prefer a setup where each webserver runs a single instance of memcached, acting as both a local and distributed cache. Very frequently accessed objects are fetched from the localhost's instance, while less frequently accessed objects can be distributed among the webservers. You'd develop a wrapper class for the memcached api that allows you to define in which mode the cache should operate for a fetch/insert. Peter, that’s correct. However, for some reason, some people don’t feel like using Memcached (took me 3 months to convince my manager).
If you want a local cache, you could run a local instance of memcached as well and connect to it using a local socket.

Personally I prefer a setup where each webserver runs a single instance of memcached, acting as both a local and distributed cache. Very frequently accessed objects are fetched from the localhost’s instance, while less frequently accessed objects can be distributed among the webservers. You’d develop a wrapper class for the memcached api that allows you to define in which mode the cache should operate for a fetch/insert.

]]> By: peter http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-2880 peter Thu, 28 Sep 2006 11:11:30 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-2880 Robin, I do not think it make sense adding the client to use APC as remote cache. MemcacheD is implemented pretty well and has decent client API (It is extension in PHP so it is faster than you would write in PHP itself) - APC is faster because it is local not because memcached is slow - I think it gets close to being as fast as you can get remote cache to be. Robin,

I do not think it make sense adding the client to use APC as remote cache. MemcacheD is implemented pretty well and has decent client API (It is extension in PHP so it is faster than you would write in PHP itself) - APC is faster because it is local not because memcached is slow - I think it gets close to being as fast as you can get remote cache to be.

]]> By: peter http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-2863 peter Thu, 28 Sep 2006 07:17:01 +0000 http://www.mysqlperformanceblog.com/2006/09/27/apc-or-memcached/#comment-2863 Kevin, Thanks. Hierarchy of caches is great of course. My main point was there might be place both for APC and Memecached, even though one may think about them being on the same layer, as they are both in memory caches. I left out squid in this case - not creating pages at and just serving them from the cache is best of course. Speaking about stats - you always need them as you can easily waste time by adding caches if your cache hit rate is too low. Besides having hit rate, I also look at timing statistics - how much does it take to store object in the cache for given object type and store it vs it normal production. This helps you to understand where to place the object - if it take just 1ms to create it you probably do not want it in disk cache but better throw it away if it does not fit in memory as creating it faster than reading from the disk. Timing information also helpful for understanding where response time comes from so you can see these 100 separate fetches from the cache are not cheap :) Kevin, Thanks.

Hierarchy of caches is great of course. My main point was there might be place both for APC and Memecached, even though one may think about them being on the same layer, as they are both in memory caches.

I left out squid in this case - not creating pages at and just serving them from the cache is best of course.

Speaking about stats - you always need them as you can easily waste time by adding caches if your cache hit rate is too low.

Besides having hit rate, I also look at timing statistics - how much does it take to store object in the cache for given object type and store it vs it normal production. This helps you to understand where to place the object - if it take just 1ms to create it you probably do not want it in disk cache but better throw it away if it does not fit in memory as creating it faster than reading from the disk.

Timing information also helpful for understanding where response time comes from so you can see these 100 separate fetches from the cache are not cheap :)

]]>