I have a project that is a results database for several sport event series. As you an imagine most the content remains more or less the same. I would like to cache some of the content to save database queries.
The project is build using PHP and is using a custom MVC. Where would you add the caching logic?
Use Memcached. Something like this, where you cache the results of the query, and try retrieving from cache before DB.
Edit: Added json_encoding the data... json_encode is slightly faster than PHP's default serialization for arrays, and can be used by other applications accessing the data
Memcached by default uses FastLZ compression.
// The ID of the item you're looking for (from $_GET or whatever) $id = 1; // Create a memcached instance $m = new Memcached(); $m->addServer('localhost', 11211); // Try retrieving the event from memcached $data = $m->get('event_' . $id); if ($data) { // If you found data in memcached, decode it for use in code $data = json_decode($data); } else { // If you didn't find the data in memcached, try retrieving from the DB $result = mysqli_query('SELECT * FROM events WHERE id = ' . $id); // If you found results in the DB... if ($data = mysqli_fetch_assoc($result)) { // Save them to memcached for future calls // Note: here, I'm using the optional param to expire it after 1 day $m->set('event_' . $id, json_encode($data), 86400); } } // Now you can use your data var_dump($data); Edited to add comments in code
mysql_* functions in new code. They are no longer maintained and the deprecation process has begun on it. See the red box? Learn about prepared statements instead, and use PDO or MySQLi - this article will help you decide which. If you choose PDO, here is a good tutorial.
mysqli_query. When you use an ORM all day, you lose the habit of referencing the underlying logic. Obviously, in this context, I assumed his Model's ORM would be supplanting the mysql function, and I was merely outlining an architecture rather than proposing a production-ready solution.There are two points where you can use caching in the MVC and MVC-inspired design patterns: the output and data retrieval:
This would have to be implemented in the views, as part of UI logic (views should be instances, not just dumb templates). Somewhere is same area where view is combining the templates in the response. Only in this case, some of the "templates" would actually be completely without variables.
This way you can cache fragments of HTML in context of MVC .. but this would no apply to your particular use-case. It's better suited for situations, when interaction with data source take too much time. Like when storage is actually REST API.
To enable this functionality it would have to be performed within model layer. To be precise: in services (classes/instances, that mostly contain interaction between domain and storage logic).
If you have a fully implemented model layer, where you separate application, domain and storage logic, then implementation of caching would simply look as different form of storage.
$user = new User; $cache = new UserCacheMapper; $user->setId( 42 ); if ( ! $cache->fetch( $user ) ) { $storage = new UserSQLMapper( $pdo ); $storage->fetch( $user ); $cache->store( $user ); } // the $user object has been initialized The initialization of objects actually should be performed by factories within the service, but this is a simplified example
This way you can create application without caching, and only later add it by modifying the services(that are responsible for application logic). Neither the domain objects (domain logic) nor the data mappers (storage logic) would have to change.
Objects can be cached using Memcache(d), which is most useful for multi server setups. For a single server, you can store things in an APC/Xcache etc which offer caching facilities.
I would cache the data in the dataaccess method.
I would used memcached as its really easy to build a cacheing solution using it http://memcached.org/
I normally put the caching logic in the controller although the model may normally be a more correct place for it, reason being that the context of model use can affect caching strategies
Putting it in the model makes the caching strategy sit with the rest of the data access functionality which is correct, it means that you can swap models and the caching code moves with it. Where this can fall down is where you have complex invalidation that cannot be put in the model.
“There are only two hard things in Computer Science: cache invalidation and naming things” Phil Karlton
You say you're using your own MVC pattern framework so it's hard to give a specific recommendation.
There are a few places you can cache.
If you use HTTP properly (idempotency, etags, cache-control headers, etc), you might benefit from placing the caching layer outside the application and using a forward cache like varnish to cache whole pages. However, it's very easy to get HTTP wrong, so this may not be the way to go. For example, if you have user accounts and the same url produces different server output depending on what user is logged in, you can't use HTTP caching because your resource depends on cookie state. (What you should do is put the user into the url, E.g. /mysite/{userid}/profile instead of /mysite/profile.) You may still be able to use varnish via its more advanced features, but it will be more difficult.
You say you are just interested in caching database query results, so I'll address that.
If you have a few well-defined queries where you want to cache a database response, you can put the logic in the controller: before you pass a model on to the view, cache it explicitly. This solution produces a messy codebase if you have multiple places to cache. Also, if you are retrieving the same data in different controllers, you will need to carefully and manually ensure that all controller code that retrieves the same models also consults the cache and uses the same cache key. Obviously, it also becomes difficult to turn caching on and off.
A cleaner solution is to wrap your models in a way that caches results transparently. This means you can add caching declaratively without making substantial changes to your controllers or models. However, this requires having a very well designed model api, which you may not have.
