Problems with APC on publish

Question

We've recently enabled APC on our servers, and occasionally when we publish new code or changes we discover that the source files that were changed start throwing errors that aren't reflected in the code, usually parse errors describing a token that doesn't exist. We have verified this by running php -l on the files the error logs say are affected. Usually a republish fixes the problem. We're using PHP 5.2.0 and APC 3.01.9. My question is, has anyone else experienced this problem, or does anyone recognize what our problem is? If so, how did you fix it or how could we fix it?

Edit: I should probably add in some details about our publishing process. The content is being pushed to the production servers via rsync from a staging server. We enabled apc.stat_ctime because it said this helps things run smoother with rsync. apc.write_lock is on by default and we haven't disabled it. Ditto for apc.file_update_protection.

Answer 1

Never saw that before, even if i'm a huge user of APC. Maybe try to trigger a script that empty the APC opcode everytime you send new code on the server ?

Answer 2

When you get a file with a parse error, back it up, then repubish. Take that same file that now works and do a diff against the file with the parse error.

Answer 3

It sounds like APC isn't preforming or getting the correct file stat info. You could check it to make sure the APC configuration apc.stat is set correctly. Another thing you could do it force the cache to clear with apc_clear_cache() when you publish new code.

Answer 4

Sounds like a part-published file is being read and cached as broken. apc.file_update_protection is designed to help stop this.

in php.ini: apc.file_update_protection integer

apc.file_update_protection setting puts a delay on caching brand new files. The default is 2 seconds which means that if the modification timestamp (mtime) on a file shows that it is less than 2 seconds old when it is accessed, it will not be cached. The unfortunate person who accessed this half-written file will still see weirdness, but at least it won't persist.

Following the question being edited: One reason I don't see these kinds of problems is that I push a whole new copy of the site (with SVN export). Only after that is fully completed does it become visable to Apache/Mod_php (see my answer http://stackoverflow.com/questions/800294/how-to-get-started-deploying-php-applications-from-a-subversion-repository/820639#820639 )

The other thing that may happen of course, is that if you are updating in place, you may be updating files that depend on others that have not yet been uploaded. Rsync can only guarantee atomic updates for individual files, not the entire collection that is being changed/uploaded. Another reason I think to upload the site en-mass, and only then put into use.

Answer 5

ctime means creation time. You will want to manually flush your entire cache every time you do updates.

You can easily do this, by putting the apc.php script somewhere on your server. This script gives you cache statistics, and will allow you to drop the cache altogether.

The script comes with APC.

Hopet his helps, Evert

Answer 6

This is probably happening because there's a mismatch between your code, and the cached versions of the code.

For example, APC has a cached version of User.php, but you made changes to User.php or to the data that User uses. The cached version is still running even after your deploy, because it hasn't expired yet.

If you clear your APC cache entries when you deploy, this issue should disappear.

Answer 7

I have the same trouble and it seems that APC doesn't update the cache with proper validation. I have 2 seconds on apc.file_update_protection but stills runs on cache and never for the the new file.

My current solution is to call to clear cache (I dislike it but...)

Do you have discovered a workaround?

Thanks Ricardo

Win32 + Apache2.2 + PHP 5.2.8 + APC 3.0.19