to the scaling issues faced by Livejournal • “memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load”
style, using Activerecord • PHP4 and objects don't mix too well • Activerecord gave us fast development but reduced performance • Call us greedy, but we want both • Use Rails Memcache!
Effectively three sites running on one codebase • Uses three seperate databases, but aiming to consolidate more • Has data namespacing implemented in most places • But seperation is not quite there yet!
daemons and connects to them over TCP • This allows us to store data once, and access it from any server, whether in the pool or not • Hashing algorithm means that a given key maps to a single server • Efficient use of memory • Efficient for cache clearing
We can • Ignore it - we simply get misses for any keys we attempt to retrieve • Remove it - our hashing algorithm breaks... :( • We can also add new servers to the pool after data has been stored, but the same hashing problem occurs
removing or adding servers once data has been hashed • Currently in its infancy - not really production ready • We simply monitor our daemons and restart if required
to improvise • Prefix your keys with a namespace by setting the namespace when you connect • Our solution: • Run multiple memcache instances on different ports
accelerates simple finds for single rows. • CachedModel won’t cache every query you run. • CachedModel isn’t smart enough to determine the dependencies between your queries so that it can accelerate more complicated queries. If you want to cache more complicated queries you need do it by hand.
Most don’t change that often • We also know when they change • Yay for the Observer pattern • User content changes much more regularly • Can be changed from outside our controlled area (e.g. Forums)
editorially controlled and user-generated • Cache editorially controlled content separately from user-generated content • Simplest way to implement is in fragment caching
Identify areas that change infrequently and cache • Remember to measure performance before and after • Evidence suggests very large gains! • Use memcache_fragments
• Great for load balancing - share across a server farm without using a DB store • Ideal for transient data • Solution exists in db_memcache_store • DB backend with memcache layer - the best of both worlds