Symfony cache processing in production

Question

I have a Symfony2 website that I am testing in production. I went ahead and cleared his cache because I did and probably will make more changes, however there is a little problem:

While the cache is clearing and saying, after which I want to warm it, the one who accesses the website restores the cache. This creates a small problem as the cache is created, but not completely, while half of it is deleted, since the deletion is still ongoing.

What happens after that, the cache is built, but only part of it. Symfony believes that the cache is fully built and works without trying to create it, but it works with a semi-developed cache. The removal process is a little long (~ 15 seconds), so no one should try to create a cache by accessing the website during this timeframe.

Either this, or the cache is completely built, it overwrites the old cache, and the system processes these new files as old ones, removes some of them and some others. Not quite sure, I'm not sure how to check this.

For example, one of the errors I received is

The directory "D:\xampp\htdocs\med-app\app\app\cache\dev/jms_diextra/metadata" does not exist. 

If I did not use this package, I would get another cache problem from Doctrine. This appears on every website until I delete the cache again WITHOUT any access to the website. it completely blocks access to the website and makes it non-functional.

Also, how about a warm up? It takes time. What if someone accesses the website while the cache is warming up? Doesn't that also create a conflict?

How to deal with this problem? Do I need to close the apache service, flush and heat the cache, and then restart apache? How is this handled with the website in production?

EDIT Something interesting that I discovered. Error deleting cache/prod folder. If I delete the contents of the folder without deleting the folder itself, it seems like an error does not occur. I wonder why.

Answer 1

It is generally recommended that you block the website in maintenance mode if you are updating or clearing the cache for any other reason during production. Sometimes a web host has this option to handle this for you, or there is a good kit for easy service from the command line.

This way you can safely remove the cache and make sure that no one is visiting the page and that the cache is being rebuilt incorrectly.

Answer 2

Usually, if you need to clear the Symfony cache, it means that you are updating the new version, so you not only need to clear the cache, but you will probably have to dump assets and perform other tasks. In this case, what I did in the past, which worked very well, is to treat each product release as its own version in its own folder, so when you install the new version, you make it not connected to the web server, but then just change your web server will point to the new version when you are done. An additional advantage is that if you break something and you need to roll back, you immediately go to the previous version.

For example, let's say your Apache configurator has a DocumentRoot , always pointing to a specific location:

 DocumentRoot /var/www/mysite/web 

You should make this root a symbolic link to your latest version:

 /var/www/mysite/web -> /var/www/versions/1.0/web 

Now say that you have version 1.1 of your site installed. You just install it on /var/www/versions/1.1 - put the code there, install your assets, update the cache, etc. Then just change the symlink:

 /var/www/mysite/web -> /var/www/versions/1.1/web 

Now, if the site crashes badly, you can just provide a symbolic link. The advantage here is that there is no downtime on your site and it is easy to roll back if you make a mistake. To automate this, I use a bash script that installs a new version and updates symbolic links using a series of commands connected via && , so if one installation step fails, the entire installation fails and you do not get stuck between the limbo version.

Of course, there are probably better ways to do all of the above or ways to automate it further, but the fact is that if you change production, you want to install / configure Symfony without letting users interfere with it.