Home Symphony Symfony2. The pitfalls of caching

Symfony2. The pitfalls of caching

by admin

Symfony2. The pitfalls of caching
It’s been 3 months since I, as a hobby, started writing a project on the new Symfony 2. In the following article I will try to share with the hubrasociety the problems a developer can face. This article is targeted at people already familiar with Symfony and Doctrine architecture.

Problem 1. Result Cache. Serializing Entities.

Doctrine 2 allows us to cache requests, but doesn’t recommend doing it with Entity.

Serializing entities can be problematic and is not really recommended, at least not as long as an entity instance still holds references to proxy objects or is still managed by an EntityManager… ( proof )

In any case, if we decide to cache a request, we need to implement a Serializable interface for each Entity. In this case, the objects that came from the cache can’t be handled correctly by the manager. It considers them as new and tries to insert them into the database again. For everything to work correctly, you should either reload the object or not use caching in this case.
Example.

//array of objects from the cache$blogs = $this-> getDoctrine()-> getRepository('BlogBundle:Blog')-> getBlogs();if ($request-> getMethod() == 'POST') {$form-> bindRequest($request);if ($form-> isValid()) {$data = $form-> getData();// create or update the post// fill in the data// ...// it won't work this wayforeach ($blogs as $blog) {if ($blog-> getId() == $data-> blog_id) {$blog = $blog;break;}}//and this will be//$blog = $this-> getDoctrine()// -> getRepository('BlogBundle:Blog')// -> findOneById($blog-> getId());//specify the blog for the post$post-> setBlog($blog);//save$em = $this-> getDoctrine()-> getEntityManager();$em-> persist($post);$em-> flush();}}

Problem 2. Symfony2. HTTP Cache and Security Component.

The caching ideology of the framework is based on HTTP specification , which allows the use of proxy caches. For example, Varnish This is a big plus because it gives the page to the client without loading the framework itself.
Symfony2. The pitfalls of caching
But this cache is useless if your site uses built in user authentication. In this case, Symfony2 creates a session for each user, treating them as anonymous. If there is a session, it means there is a unique cookie. The result is that the cache works for each visitor separately because it treats users as anonymous.
I haven’t found a solution to this problem yet. Perhaps the hubracommunity can help.
Also, Symfony2 is not a caching ideology and should not be used in projects where the content is changed based on user authentication. For example, a vote for a thread in a hubre where the following states exist: you can vote, I voted positively, negatively, voting is over, etc. Or, for example, a form to add a comment to a publication, where there is the possibility of commenting by anonymous users as well.

Load test.

By happy coincidence I have two projects with similar functionality. One is written in Symfony 1.4 and the other in Symfony2.
Strangely enough, a simple load test of the main pages showed that the Symfony 1.4 project is faster:

  1. Symfony 1.4 approximately 2550 requests in 30 seconds with a competition of 10.
  2. Symfony2 approximately 1750 requests in 30 seconds with a competition of 10.

Projects are hosted on a dedicated server with a quad core processor (Intel Core2 Quad CPU Q9550) and 8G of RAM.
Sites where tests were conducted :

  1. http://dreamiech.ru — Symfony 1.4
  2. http://dvjournal.ru – Symfony 2

You may also like