Sriram Natarajan wrote: > > > Jeff Trawick wrote: >> Nick Kew wrote: >>> >>> On 20 Feb 2009, at 15:05, Jeff Trawick wrote: >>> >>>> (a simple diversion I hope from the other thread; I'll get back to >>>> that as soon as practical, and I appreciate the contributions there) >>> >>> OK, this one's much simpler. >>> >>> +1 to your proposals of not autoloading proxy, cache, and all-authnz >>> with the proviso that basic file-based auth should probably be >>> supported >>> by default for the benefit of newbies following recipes found on the >>> 'net. >>> >>> OTOH, these'll still have relatively little effect on memory footprint. >>> That's more up to scripting modules, especially if _they_ load the >>> kitchen sink. >>> >> Oh, shoot; I missed the boat on the optional module packages, and >> especially a specific scripting module; thanks! >> >> Starting with the minimal SUNWapch installation, vsize is only 12MB >> (perhaps mostly wasted, but not in the danger zone). >> Add jk and it grows only slightly. >> Add dtrace and it grows only slightly. >> Add just mod_php (no extensions) and it jumps to 23MB. > here, you refer mod_php delivered by opensolaris or you compiled it on > your own with very minimal extensions ?
mod_php delivered by OpenSolaris, via package SUNWapch22m-php5 (I missed adding the "2" at the end, but this "php5" package depends on SUNWapch22m-php52 so it shouldn't make a difference; SUNWapch22m-php52 doesn't depend on SUNWphp52) Because that didn't pull over SUNWphp52, I had no extensions loaded. Later I added SUNWph52 with the extensions. >> Add the main PHP package, which brings with it a number of extensions >> loaded by default, and we're up to 60+ MB, clearly in the danger zone). >> > Does this also include PHP/MySQL combo ? PHP main package delivers the > following extensions enabled by default - apc, curl, ldap, bz2, zlib, > memcache, openssl, sqlite. dtrace, gd, gettext, ftp, idn, tcpwrap, > iconv. We have not investigated as to which of these extensions are > the big memory consumers but not frequently used by common php > developers and disable them by default . This is one option. For > example, we could consider delivering extensions like memcache , ftp > etc disabled by default if could help > I have the modules loaded by the default .ini files that you listed; I don't have the PHP/MySQL interface. /usr/php/5.2/modules/apc.so /usr/php/5.2/modules/bz2.so /usr/php/5.2/modules/curl.so /usr/php/5.2/modules/dtrace.so /usr/php/5.2/modules/ftp.so /usr/php/5.2/modules/gd.so /usr/php/5.2/modules/gettext.so /usr/php/5.2/modules/iconv.so /usr/php/5.2/modules/idn.so /usr/php/5.2/modules/imap.so /usr/php/5.2/modules/ldap.so /usr/php/5.2/modules/memcache.so /usr/php/5.2/modules/openssl.so /usr/php/5.2/modules/pdo.so /usr/php/5.2/modules/pdo_sqlite.so /usr/php/5.2/modules/sqlite.so /usr/php/5.2/modules/tcpwrap.so /usr/php/5.2/modules/tidy.so /usr/php/5.2/modules/zlib.so (all of the SUNWphp52-bundled extensions but suhosin and xdebug) $ pkg list -a | grep php SUNWapch22m-php5 2.2.6-0.101 installed ---- SUNWapch22m-php52 5.2.6-0.101 installed ---- SUNWphp52 5.2.6-0.101 installed ---- SUNWphp52-mysql 5.2.6-0.101 known ---- SUNWphp52-pear 5.2.6-0.101 known ---- SUNWphp52-pgsql 5.2.6-0.101 known ---- SUNWphp524 5.2.4-0.101 known ---- SUNWphp524-mysql 5.2.4-0.101 known ---- SUNWphp524-pgsql 5.2.4-0.101 known ---- SUNWphp524core 5.2.4-0.101 known ---- SUNWphp524doc 5.2.4-0.101 known ---- SUNWphp524man 5.2.4-0.101 known ---- SUNWphp524usr 5.2.4-0.101 known ---- SUNWphp52d 5.2.6-0.101 known ---- libnb-php 6.5-0.86 known ---- netbeans-php 6.5-0.86 known ---- >> For the typical OpenSolaris installation which will have PHP >> available, the Apache diet on its own doesn't change the big picture >> for swap space allocation requirements. >> >> Unless someone has a pragmatic way to address the PHP issue, there's >> no silver bullet. FastCGI is a potential solution but that seems a >> drastic change for the OOB experience. >> >> (If PHP can't go on a diet without consumability issues, then this >> should fall into the doc delivery.) >> > If you have more thoughts on what could be the acceptable limit, > please file a bug . I will investigate further on how PHP can go on > diet .. unclear on what the acceptable limit is given the constraint of maximum consumability I think PHP is markedly different from Apache in this area because PHP extension use is governed by the application, and someone who can install a PHP application won't necessarily have a clue about the PHP configuration and wouldn't ordinarily need to touch it; in the Apache examples I listed, the user has to touch the Apache configuration anyway to make the loaded feature do anything.
