Re: [development] How many modules is too many?
(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.
Khalid Baheyeldin wrote:
(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-... Great article... Has anyone figured out what parts of the module architecture are most expensive memory-wise so they can be examined?
Mike
On Nov 30, 2007 2:17 PM, Mike Cantelon <m_cantelon@straight.com> wrote:
Khalid Baheyeldin wrote:
(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-...
Great article... Has anyone figured out what parts of the module architecture are most expensive memory-wise so they can be examined?
Yes. a) The include_once() part is the most expensive. That is common for all modules, and the more you have the more you suffer (but there are solutions). b) Creating large associative arrays (e.g. the way we handled URL aliases before 4.7). c) Doing a lot of things over the network (e.g. subscriptions module and Google Sitemap module with certain settings. One emails people, the other pings Google). d) Lack of an op-code cache/accelerator. e) Excessive SQL queries, either number of queries or heavy ones. (Just saw a site with 11,400 queries per page. Ended up being badly written PHP code pasted in a block that loads on every page). For a) I am writing an article with more details on the include_once part over the weekend (if not sooner). For c) and d) there is an article or two on 2bits, one with the exact settings that causes slowness. -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.
participants (2)
-
Khalid Baheyeldin -
Mike Cantelon