Re: Using the pear installer (or pyrus) as an applicationdeployment tool

Stephan Wentz wrote: > Am 28.10.2009 14:46, schrieb Greg Beaver: >> Stephan Wentz wrote: >> >>>> An alternative to this would be to distribute the contents as a phar >>>> which would preserve everything and prevent inadvertent modification. >>> >>> Phar was my first thought, too. But with that many components (and >>> thus, >>> phars) my tests really didn't produce very good performance - it was >>> something like 3 times slower. APC was enabled, I didn't look deeper >>> into this and why it's getting so slow. >>> Did anyone here in this group run some tests with lots of phars (not >>> only one)? >> >> Did you try enabling phar.cache_list? >> >> >> http://us.php.net/manual/en/phar.configuration.php#ini.phar.cache-list >> >> That tends to make performance much better, although it won't match APC >> outside of a phar, because all files must route through PHP and phar, >> losing some of the webserver efficiency. > > Yea, did some performance testing with it. It works fine, and is > nearly as fast as without phar, but it's really a hassle to maintain. > Don't think this is an option for us. > > Hmm, or maybe... Can this setting be overriden by virtualhosts? Or is > it a fixed value that's only allowed in the main php.ini? http://us.php.net/manual/en/ini.sections.php Looks like you're in luck should you go this route AND are running fastcgi (mod_php doesn't work with this). Of course, you can go the .htaccess route as well php_admin_value phar.cache_list "path1:path2:path3" This isn't really a PEAR-specific conversation, so if you want to continue it (and I am happy to do so), I'd suggest sliding over to php-general. Greg