Plugin sfPropelMemcachePlugin

Continuing the topic that I started in the articles “ ORM is evil or How I tried to cache Propel in Symfony ” and “ How I made friends with“ memcache ”and Propel in Symfony ” I want to talk about how my attempts to cache the data model resulted .


Briefly about what was in the previous articles ....
Initially, on the project that I mean, the view cache was used. But this approach created a number of inconveniences for me and my colleagues:

1. complexity of data validation: when writing to the database, it was necessary to reset the data of various related blocks, because of this confusion, errors often occurred.
2. excess data in the cache: the html result is cached, not the data from the database. More data, more load, longer loading. Trifle of course. But still!

So, we decided to cache the model. What is needed for that? After studying the classes generated by Propel on this subject, it was decided to use a pool located in PEER classes. According to the ORM developers, this pool stores objects created and already in the database (isNew == false). Propel adds an object to the pool when it is received via the doSelect / One / ... methods. At the same time, it checks for the presence of an object in the same pool only when calling the retriveByPk method. Based on this, object links using unique keys can also use the cache if we use the methods of retriveBy ... (more details in previous articles) ....

In the course of all these conclusions, the plugin sfPropelMemcachePlugin was written, which implements all this, and in my opinion quite successfully:

1. The cache size has decreased from 400 Mb (this is the maximum in the cache settings) to 100mb.
2. No confusion with validation. The model has changed, the cache has changed. Templates are not cached for the most part, it's easier to typeset.
3. Simple queries are used in the database for the most part on the primary (or unique) key.

The plugin currently supports caching using primary, unique, and composite keys.
')
The plugin is still a batch, so do not judge strictly.

Schedules of the plugin in the production.
The user model, its profile, countries, districts, cities, photos (+ avatars), folders of photos are cached.









The plugin itself.

PS I am pleased to hear constructive criticism and suggestions.