Assuming a MySQL datastore, when would you NOT want to use memcached in a Ruby on Rails app?
+9
A:
Don't use memcached if your application is able to handle all requests quickly. Adding memcached is extra mental overhead when it comes to coding your app, so don't do it unless you need it.
Scaling's "one swell problem to have".
Douglas F Shearer
2008-09-30 16:42:46
+1 . Starting new apps off w/memcached is premature optimization. Don't add un-necessary complexity from the start!
Matt Rogish
2008-09-30 18:02:56
@Matt - sometimes you just know how much your app needs to scale, and caching will be required. Adding memcached (or any distributed cache) from the start is not *always* premature optimisation.
DanSingerman
2009-04-01 22:40:49
@Douglas F Shearer - memcached is baked into Rails 2.3, so I don't think there is any mental overhead. It's just a config setting - config.cache_store = :mem_cache_store
DanSingerman
2009-04-01 22:56:24
+6
A:
Memcache is a strong distributed cache, but isn't any faster than local caching for some content. Caching should allow you to avoid bottlenecks, which is usually database requests and network requests. If you can cache your full page locally as HTML because it doesn't change very often (isn't very dynamic), then your web server can serve this up much faster than querying memcache. This is especially true if your memcache server, like most memcached servers, are on seperate machines.
Flip side of this is that I will sometimes use memcache locally instead of other caching options because I know someday I will need to move it off to its own server.
Aaron
2008-09-30 17:56:33
This completely ignores the main benefit of memcached - that it is a *distributed* cache.
DanSingerman
2009-04-01 22:42:37
A:
When you want to have fine-grained control about things expiring. From my tests, memcached only seems to have a timing resolution of about a second.
EG: if you tell something to expire in 1 second, it could stay around for between 1 and just over 2 seconds.
Orion Edwards
2008-10-01 00:58:35
+2
A:
The main benefit of memcached is that it is a distributed cache. That means you can generate once, and serve from cache across many servers (this is why memcached was created). All the previous answers seem to ignore this - it makes me wonder if they have ever had to build a highly scalable app (which is exactly what memcached is for)
Danga Interactive developed memcached to enhance the speed of LiveJournal.com, a site which was already doing 20 million+ dynamic page views per day for 1 million users with a bunch of webservers and a bunch of database servers. memcached dropped the database load to almost nothing, yielding faster page load times for users, better resource utilization, and faster access to the databases on a memcache miss.
(My bolding)
So the answer is: if your application is only ever likely to be deployed on a single server.
If you are ever likely to use more than one server (for scalability and redundancy) memcached is (nearly) always a good idea.
DanSingerman
2009-04-01 22:39:32