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 ? > 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
> 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 .. thanks sriram > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
