SfPropelMemcachePlugin plugin
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 what my attempts to cache the data model resulted in .
Briefly about what happened in previous articles ....
Initially, the project I used used the view cache. But this approach created a number of inconveniences for me and my colleagues:
So, we decided to cache the model. What is needed for that? Having studied the classes generated by Propel for this subject, it was decided to use the pool located in the PEER classes. As conceived by 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 through doSelect / One / ... methods. At the same time, it checks for the presence of an object in the same pool only when the retriveByPk method is called. Based on this, the connection of objects by unique keys can also use the cache, if we use the retriveBy methods ... (more in previous articles) ....
In the course of all these conclusions, the sfPropelMemcachePlugin plugin was written , which implements all this, and in my opinion is quite successful:
The plugin currently supports caching using primary, unique and composite keys.
The plugin is still beta, so do not judge strictly.
Plugin work schedules on production.
Cached model of the user, his profile, countries, areas, cities, photos (+ avatars), folders of photos.
The plugin itself .
PS I will gladly listen to constructive criticism and suggestions.
Briefly about what happened in previous articles ....
Initially, the project I used used the view cache. But this approach created a number of inconveniences for me and my colleagues:
- complexity of data validation: when writing to the database, it was necessary to dump data from various related blocks, because of this confusion errors often occurred.
- excess data in the cache: html-result is cached, not data from the database. More data, more load, takes longer to load. A trifle of course. But still!
So, we decided to cache the model. What is needed for that? Having studied the classes generated by Propel for this subject, it was decided to use the pool located in the PEER classes. As conceived by 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 through doSelect / One / ... methods. At the same time, it checks for the presence of an object in the same pool only when the retriveByPk method is called. Based on this, the connection of objects by unique keys can also use the cache, if we use the retriveBy methods ... (more in previous articles) ....
In the course of all these conclusions, the sfPropelMemcachePlugin plugin was written , which implements all this, and in my opinion is quite successful:
- The cache size decreased from 400 Mb (this is the maximum in the cache settings) to 100mb.
- There is no confusion with validation. The model has changed, the cache has changed. Templates for the most part are not cached, it is easier to typeset.
- Simple queries to the database are used 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 beta, so do not judge strictly.
Plugin work schedules on production.
Cached model of the user, his profile, countries, areas, cities, photos (+ avatars), folders of photos.
The plugin itself .
PS I will gladly listen to constructive criticism and suggestions.