Hello, We've tried all three and are just not convinced they are functioning correctly with peruser and chroot.
Eaccelerator for example doesn't seem able to detect properly which scripts it should remove once that script has no longer been accessed for a while, if you tell it to remove expired scripts (scripts that haven't had a cache hit in the specified TTL value) it simply removes *all* cached script whether the scripts have been marked expired by itself or not. This does not happen with Eaccelerator on a non-peruser server. This makes us wonder if it's actually functioning correctly in other ways. Also say you have two users who have installed WordPress, you end up with: /home/user1/public_html/wp-config.php /home/user2/public_html/wp-config.php but Eaccelerator (and xcache, APC) only see this: /public_html/wp-config.php as the file path. Do we know if it is serving the correct file when a request comes in from user1 or user2 or whether it thinks they are the same file because of the chroot path? I'm just wondering if anyone has come across this before with peruser + chroot and knows whether these tools are working correctly despite the chroot? Or whether there is a way to feed the full path to these opcode caching tools while using peruser + chroot. Thanks, Andrew On 11 Jan 2011, at 15:22, Hannes Landeholm wrote: > Hello, > > I do this/plan to do this with APC. (Thanks for the patches BTW!) > > I haven't done any careful testing yet but I don't see the problem of why APC > would not be compatible with chroot. The whole point of chroot is to keep > virtual hosts separate from each other. This should not result in any > duplicate caching of PHP files or additional memory as virtual host B can't > see virtual host A's PHP files and so cannot cache them anyway. Unless you > are have a lot of virtual hosts that are subset of other virtual hosts. But > that would be really odd and you'd probably have to live with the extra > memory then.. > > Please elaborate on why they wouldn't function properly. > > Regards, Hannes > > > > On 11 January 2011 16:14, Andrew <[email protected]> wrote: > Hi, > > Does anyone have any experience of running peruser + chroot with PHP opcode > caching software (e.g. eaccelerator, xcache, APC)? > > As you'd expect none of these caching systems are able to see the full path > of the files they are trying to cache when peruser has chroot enabled. This > causes them not to function. > > If we chroot as such with peruser: > > Chroot /home/username > > they opcode caching systems only see PHP files as having the path: > > /public_html/path/to/file.php > > Which causes problems in a multi-user system. > > All of the opcode caching systems are compiled as PHP modules. Are there any > work arounds? Has anyone successfully modified one of the big three caching > systems to work with peruser and it's chroot system? > > Thanks, > > Andrew > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser > > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser _______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
