Re: Feature request : Self caching of .php files for wide multi backend setups.

From: Date: Fri, 03 Aug 2007 17:25:35 +0000
Subject: Re: Feature request : Self caching of .php files for wide multi backend setups.
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-31441@lists.php.net to get a copy of this message
Hi Constantin, That is quite a difficult setup you have there. You should have a look if there is not a simpler way to accomplish whatever this setup is for. That said, you should have a look at DRBD (http://www.drbd.org), which should be able to solve your problems. It detects file changes on a low level and synchronizes it to other systems. Setting up DRBD isn't an easy task though, but hard problems usually have hard solutions ;). Good luck, Arnold Rasmus Lerdorf wrote:
There is nothing simple about it when it comes to a portable implementation across all platforms which is what it would have to be if it was in PHP. In your case, you don't need it to be portable, you just need it to work on your configuration, and there are all sorts of ways you can solve it without changing PHP. For example, even without any fancy file system layers, a simple cron job that checks the local files against the NFS/rsync/remote copy every couple of minutes and updates the files atomically would solve your problem as well. Adding a complicated caching layer in PHP just so you don't need to write a little cronjob script makes no sense to me. -Rasmus Constantin B wrote:
I was thinking that portable and very simple implementation in php would be much more used in real world than these experimental too abstract implementations. but i guess i'm wrong. 2007/8/3, Rasmus Lerdorf <rasmus@lerdorf.com <mailto:rasmus@lerdorf.com>>:
    Constantin B wrote:
Hello, i'm not sure its the right place to post this message, so redirect
    me if i'm
wrong. Here the problematic : We are alot running php across multiple backend servers and we all
    know that
we need to syncronise the php sources usualy we do that with rsync
    , some of
us run all backends on an NFS feed. -> the usual problem is that the developpers like to see their
    changes in
"live" and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper
    localcache:/ we could
get all require / include / require_once / include_once functions
    to make a
local copy of needed files then require / include them as usualy. here an exemple : require("/path/to/file.php"); // the /path/to/file.php is on an
    nfs mount.
require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later
    // it
just require it as now 3 : if the file does not exist or if its too old we refresh it
    from the
/path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the
    "holly
rsync" 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http
    also . (at
step3 ) this remove the need of nfs at all. This would allow us to run large backends without the
    syncronisation issue .
And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we
    do it
early it will not notice that the file was refreshed from "remote". Its just an idea but i'm sure it can be realy usefull for big farms.
    This doesn't sound like something that should be part of PHP at all.
    This is a generic file system caching mechanism which can be implemented
    using FUSE.  There are even implementations out there of an rsyncfs
    which pretty much does exactly what you are looking for.
    -Rasmus
    


« previous php.internals (#31441) next »