0
votes

I'm working on a project where doctrine cache is not active. We are experiencing some performance issues and I am wondering if activating doctrine cache would lead to possible regressions.

Here is why i'm asking about it:

I visualize the 3 cache type:

  • metadata_cache_driver
  • result_cache_driver
  • query_cache_driver

The most important one for me is the result_cache_driver. And i'm not sure of how it works. Here is what I imagine:

We have an entity "book". If we create a dql query, or use findBy doctrine method to get all books written in 1975, it will return let says 75 books. This result is store in cache and next time we call it, it will not request the DB but get the result from cache.

Now we update the entity with DQL or doctrine ($book->setYear(1976)). I guess the cache for the entity book will be reset and next time we request for all book written in 1976 it will return 74 books.

Bu what if we update the DB using SQL: UPDATE book set year = 1976 where id = XXX. Will it clear the cache for this entity and request the DB when we ask for all book written in 1975? Or will it still use the cached result and return our updated book which is not in 1975 anymore?

To summarise, there are 3 way to update our DB:

  • using doctrine entities (for single update)
  • using dql query
  • using sql query (for mass update)

So does the doctrine cache result take into account those 3 way? Or will there be some case we will have to wait the cache timelife end to get the new right result?

1

1 Answers

1
votes

As you said, there is three kind of caches and they are very useful for your application performances.

Query Cache: It doesn't make sense to do this parsing multiple times as it doesn't change unless you alter the DQL query. So, yes it make sense to use the query cache especially in production environment which cache the transformation of a DQL query to its SQL counterpart. As example, except a search realized by users, I cache all my queries to avoid the transformation process and gain performance.

Metadata Cache Your class metadata can be parsed from a few different sources like YAML, XML, Annotations, etc. Instead of parsing this information on each request we should cache it using one of the cache drivers. In production, your class metadata won't change. So why do not let the metadata cache do its job?

Result Cache The result cache can be used to cache the results of your queries so that we don't have to query the database or hydrate the data again after the first time. The hydratation process can be avoid. You just need to configure the result cache implementation. If you have some resources in your application which never changed (List of countries, list of cities), you should them and set a long cache lifetime to gain a lot of performance.

If you have data that change a lot of time, you could avoid cache, but I think that the doctrine cache is still useful. For example, what happened if your calling your users three times in your code (once to test the access token, one more time to test security and a last one to set its last activity), doctrine result cache will avoid two sql and two hydratations.

If you have data that only change when admin do an update of settings (the description of an item selled on your online shop), you should cache them. When admin update them, you clear the cache.

Performance can be estimated with acceptance tests. (Have a look on Codeception) You can install your application on your qualification platform and clear and warmup cache. Then you launch test with/without cache and you can compare time of execution.