(Changing the subject) I regularly see 80+ to 110+, and that causes Apache to eat 100MB per process, which is really not good ... This is the open buffet binge syndrome detailed here: http://2bits.com/articles/server-indigestion-the-drupal-contributed-modules-... On Nov 21, 2007 12:50 PM, Jim Li <jimmydami@gmail.com> wrote:
Cool, thanks! It'd be interesting to have a poll on how many modules people use on a social network site. I heard someone uses 160 modules at his dev site, it may go down a bit later, but it probably will still in the 100+ ragnge :)
On Nov 20, 2007 6:31 PM, Earl Miles <merlin@logrus.com> wrote:
On the other hand, having 150+ modules load *is* going to eat a whole lot of memory; so actually activating all these modules is a really bad idea.
And yes, the modules page under 4.7 is going to choke like [insert really bad sports team metaphor here].
Sean Robertson wrote:
As I understand it, Drupal 5+ no longer does that. That's what the .info files are for. Those files are only a couple hundred bytes each so the full page even with a ton of modules downloaded should only use a small amount of memory unless you enable them all (which would affect all pages, not just that one).
Jim Li wrote:
Hello,
I saw some complaints that admin/build/modules page loads all modules and eats up lots of memory. And I heard a story that somebody new to drupal was trying to evaluate >150 modules and eventually drupal 'crashed' on this page due to memory limit. So I am just wondering is it a good idea that we use tabs to separate module groups on admin/build/modules page? Will it help with the problem? We can have three tabs: core, contrib, oh and uninstall (which will need some speical css rendering).
Thanks, Jim
-- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.