Which is the difference between ./bin/console cache:clear --env=prod and rm -rf var/cache/prod/*? Console command is very slow. Bash command is fast. So, ... why use cache:clear instead of rm?
cache:clear wipes previously created cache items, but also, it does a cache warm-up. Upon this, you application should load very fast due to the fact that cache was already pre-populated.
On the other hand, rm -rf does only one part of the job. You should notice performance impact when you try to load you app the first time after this.
I would also like to point out another thing: permissions. If you are logged in as root for example, and you did not set access rights via setfacl (or any other method), cache:clear will most probably create your cache items owned by root. This could be an issue, down the line.
Hope this helps a bit...
"cache:clear" command not only removes the cache but they usually build the updated cache data (warm up) so that symfony does not have to create one after the first request comes, which is the reason that it takes more time than the mere removal of files under your cache folder by "rm -rf".
Even if you can finish that command faster, it would take time for you to process the first request, if you have not created cache in advance by this command.
http://symfony.com/doc/current/console/usage.html
So, usually it is better to run cache:clear, at least in the whole process of deployment.
The occasion you would use rm command is usually only when some file permissions have gone wrong (i.e. maybe you had run a command with a wrong user ) and there were no choices left, I think.
almost all commands:
cache:clear Clears the cache
cache:pool:clear Clears cache pools
cache:warmup Warms up an empty cache
doctrine:cache:clear-collection-region Clear a second-level cache collection region.
doctrine:cache:clear-entity-region Clear a second-level cache entity region.
doctrine:cache:clear-metadata Clears all metadata cache for an entity manager
doctrine:cache:clear-query Clears all query cache for an entity manager
doctrine:cache:clear-query-region Clear a second-level cache query region.
doctrine:cache:clear-result Clears result cache for an entity manager
Related
I have bee using Symfony for a while now, and recently ran into an issue where the app/console cache:clear didn't want to clear the cache.
I then discovered that you can manually remove the app/cache directory to clear the cache.
So aside from doing the app/cache folder, what does cache:clear actually do? Why would i keep using it rather than removing the cache folder?
It also does the cache warmup (at least in version 3.1, which I'm currently using) unless you tell it not to do so with --no-warmup.
It's also easier and faster to run commands in IDEs like PHPStorm then manually doing things such as removing files.
Basically you can just remove cache directory if you prefer such way. Cache warmup will be performed at first Symfony request is needed.
You can also attach event to clear some of your custom cache.
This mean if you remove cache directory, you're not sure to clear custom cache handling
I have a website in Symfony linked to a a MySQL database. The website is having some troubles, so I have to update the information in the database. The thing is, when I update on the database, it stays updated there but on the website it doesn't show any changes.
For example, a user is registered. I go to the database to change the email so I can register another account with the same email. The database is updated with the new email, but on the website it says that the old email is still in use.
I know that I am updating the right database, because when I register a new client on the website, it appears on the database. Any ideas on to why this might be happening?
Like Angel Iliikov mentions in the comments, it's very likely a caching issue. The following suggestions assumes you have access to the command line - which a typical Symfony user should. If you don't already have it, most hosting providers allow you to get SSH access.
Clear the following caches:
1. Symfony's cache
Symfony will store a lot of data in the cache files to prevent it from having to process requests from scratch. When Symfony apps go wonky, a very common fix is to clear this cache and retry. The standard way to clear this cache is with a console command run at your project's root directory:
$ app/console cache:clear
If you run into issues, David Soussan answer provides more information on this one.
2. Doctrine's cache
According to commenters on another question (formatted by me):
The doctrine cache is often stored in apc rather than in the file
system so removing the cache files would not help. The general app/console cache:clear is only for the symfony (app) cache. I don't think it clears the doctrine cache(s).
-caponica
Alternative PHP Cache (APC) is an optional component enabled in php.ini. It's possible Doctrine is caching information there as well if it happens to be enabled.
The accepted answer on the previously mentioned question provides an answer for clearing Doctrine's cache:
$ app/console doctrine:cache:clear-metadata
$ app/console doctrine:cache:clear-query
$ app/console doctrine:cache:clear-result
-amitchhajer
3. Your browser's cache
This is very unlikely to be causing any issues. But if you are doing something to send caching headers over HTTP - it's possible that the application would have properly updated the data, but your browser is displaying an old page.
Each browser has a different way of clearing cache. Google provides support for how to do it Chrome. and Mozilla provides support for how do it in Firefox.
If clearing the cache doesn't solve your problem, it's likely a problem with your application or workflow and will need debugging. A few things you can try:
Make sure you really updated the correct database. Confirm this
on two separate DB clients.
Create your own Symfony
command
where the only thing you do is query the database. If it returns the correct result, you should check that other components are using the same query. If not, check your config/parameters to ensure you're using the right database.
If your Symfony application is not showing the updated database record that is because it is using the cache which still contains the old data. This is often a problem with Symfony, refreshing the page just reloads from the cache. Try clearing the cache first. Now, very often cache:clear does not work from the command line, I've had it happen all the time and never really understood why. The answer is to just delete all the cache files, as per Fabien Potencier's tip: http://fabien.potencier.org/a-symfony-tip-clear-the-cache-without-the-command-line.html. That works and is my go-to solution for when eg; composer update did not clear the cache afterwards. In fact I got into the habit of just deleting the cache files on my dev machine before doing composer install or update.
Adam,
Use these commands to clear your cache:
# dev environment
$ app/console cache:clear
# production environment
$ app/console cache:clear --env=prod
I had problems using the mysql database supplied by my host server at first but then I installed the latest mysql database version available in softaculus inside my host server and then I was able to access mysql inside softaculus or directly by the url (www.mypage.com/mysql). Finally it works perfectly. You can try to do something similar.
I am using Laravel's file caching system (at least temporarily) to cache numerous smaller, mainly static objects from the database. However, if I use artisan to run some functions (which add/call from the cache) and then try to load a webpage, I get permission errors while trying to access the cache. Same error when done the other way around (view web page and then run artisan).
This is because the cache is owned by me when I run an artisan command, but is owned by apache when run through the webpage.
I have thought of 2 solutions. One, delete all the cache at the beginning and end of all artisan calls (not ideal, loses most of the performance boosts). Or, run all my artisan commands as the apache user (not convenient, and maybe not even possible).
Is there a way to modify the permissions automatically of Laravel's file caching? Or set artisan's caching to use the apache user maybe?
Not the most elegant solution, but I ended up just removing caching from my artisan commands. These were just background tasks that did not need the same speed boost as the front end does.
You can try to chmod the storage folder to 0777. You can do this using your command line.
$ chmod --help
I am using Symfony2. I have a config.yml with users setting. In my development environment, if I change the list of users and refresh the browser, I see the change immediately. In production, I do not see the change, even though I have tried clearing the cache. What do I need to do to see the configuration change in production?
Try to clear the production cache with this command :
php app/console cache:clear --env=prod --no-debug
It it doesn't work, clear the content of the cache folder.
I'm using LAMP with CodeIgniter for one of my projects; version controlled by SVN. Every time I execute svn export file:///svnrepo/project/trunk/www . --force when in the www directory and then reload the web page, it goes blank.
The website only shows up after I do a service httpd restart (Using CentOS 5).
I want to be able to execute the svn export using a Phing build script in the future and I don't want to have to get root privileges and restart apache every time when I do a build.
Is what I'm experience a common problem? How do I solve it without restarting apache?
Edit:
It seems someone has had this problem before: http://codeigniter.com/forums/viewthread/181642/
Ok I got it.SVN maintains a files last modified time which throws off the APC cache. So to solve it we update the last modified time of all the files after we run an SVN export. Here is my final script:
#!/bin/sh
svn export --force file:///home/steve/repo/exmaple/trunk \
/home/steve/public_html/example.com/public/
find /home/steve/public_html/exmaple.com/public | xargs touch
You can find more details here.
An alternative solution would be to set apc.stat=0 (reference) in the apc.ini, and then use apc_clear_cache() (reference) to force the removal of the opcode cache.
What's awesome about this solution is that when apc.stat is set to 0, it disables the check on each request to determine if the file has been modified. This results in a huge performance boost.
Additionally, using apc_clear_cache() to clear the APC cache tends to result in a cleaner build. I've run into wonky race conditions where certain files will get built out that have dependencies on others that have not yet been built out. This results in a spat of FATAL errors. The only caveat here is that apc_clear_cache() needs to be run via apache, so you'll need to implement a wgetor something similar for this.