Apache doesn't immediately notice a change in the document root
Posted
by
Tom
on Server Fault
See other posts from Server Fault
or by Tom
Published on 2012-03-27T14:01:08Z
Indexed on
2012/04/06
5:32 UTC
Read the original article
Hit count: 512
We use capistrano for website deployments and our Apache document root is a symlink to a particular code release. The deployment procedure switches the symlink from the old release to the new release as the final step of the deployment.
We are migrating our webservers from real servers running RHEL 5.6 to Amazon EC2 virtual machines running Ubuntu 11.10 and the new servers are suffering from a problem where Apache doesn't immediately notice the change to it's document root when the symlink is switched. It can take a second or so (and I think I've even seen it take a couple of minutes). It's kind of like Apache has cached the physical path of the symlink for some time.
Does anyone know some Apache settings I could look at to get it to "scan" for changes to it's served files quicker.
Thoughts:
- I read that the disks on virtual machines are much slower (since they are network attached storage). Perhaps the filesystem cache somehow works differently too? If so, is there anything that can be done?
- The website runs PHP code. Perhaps there is some PHP config differences between RHEL and Ubuntu? I checked
realpath_cache_ttl
but both servers have it commented out:
e.g.
; Duration of time, in seconds for which to cache realpath information for a given
; file or directory. For systems with rarely changing files, consider increasing this
; value.
; http://www.php.net/manual/en/ini.core.php#ini.realpath-cache-ttl
;realpath_cache_ttl = 120
- We do use the APC opcode cache but don't think it's the issue due to experimentation. The PHP code is in different file paths for each deployment and we ensure
stat=1
. - Here is a similar question that is very interesting: 294107 - but doesn't provide an answer for me.
- One solution would be to reload Apache everytime we modify the document root symlink. I'll do this if we can't find another solution.
© Server Fault or respective owner