[support] problem with too many modules

[Matej Svetlik]

hello, 
thanks for all replies

here is what i got so far:

> The main problem is that Drupal 5 and earlier by design loaded ALL
code on 
> every page load.  In Drupal 6 we introduced split include files for
page 
> callbacks, so most of those "foo.admin.inc" and "foo.pages.inc" files
are not, 
> in fact, loaded on every page request but only when needed.  There are
similar 
> techniques that individual modules can implement if necessary for
their own 
> code, and some of the larger ones like Views and CCK do, but there's
no 
> central mechanism for it.

All my modules are split to many .inc files loaded only when needed. But
drupal 
still includes all 67 .module files.

> Hooks aren't the issue per se, although it is true that there's a cost
to 
> checking 50 modules for a hook.
> 
> Both of those are seeing major improvements in D7, but they're not
anywhere 
> near production ready yet.


> An opcode cache will help immensely for the first problem, as that's
the main 
> thing it solves.  Proper tuning of the cache (you can set it to not
even stat 
> the disk) will help, too.
I tried APC ... load times are faster but not enough :D
(according to APC stat, there is enough cache memory and other settings
seem OK too)
I tried turn off file modification chceking ... not much improvement
and APC include_once hack ... with that option set, drupal refused to
start ...

> Beyond that, depends on your modules.  You may find some you do not,
in fact, 
> need.  
Actually, problem is that i need all of them ;). There are few core
modules. All other modules are custom and are used daily. (Most of them
are just form and "do-something-with-external-system" when submitted.)

> Others you could look into improving by implementing some sort of
lazy-
> loading mechanism like Views does.  (I believe Views' mechanism is
being split 
> off to the ctools module, now in alpha.)  You'd have to work with the 
> maintainers for those.  Some modules wouldn't really support it,
sadly.
> For external systems, definitely look into proper caching, even if you
think 
> it's fast.  You can also look into tuning the block cache, or using
memcache 
> instead of the default db caching, perhaps, but that's probably
overkill if 
> you are just running an intranet server.

Problem with caching is that all modules use "live" data, or are
generating unique reports. I can't cache anything.

> Anyway, that's just general purpose advise.  And, um, no, don't hack
core.  
> Really.  You will regret it.  Maybe not today, maybe not tomorrow, but
soon, 
> and for the rest of your life.

I know that hacking core is the last resort and is generally bad
idea :D.

-------------------------------------------------------------------------------------------------

And there is another thing that can help: I need that only one module
(used most and in critical process) should be as fast as possible. So i
tried little trick:
There is function list_modules in core returning list of modules witch
are then loaded. As i only need one module to be as fast as possible and
i don't really care about others. In the list_modules function i check
witch module is being loaded (something like if $q is like /is/*). If
it's my module - instead of full module list, I return manually created
reduced module list. Result is that only 17 modules out of 67 are
loaded ... but the problem is that it didn't helped much :( - maybe the
bottleneck is somewhere else and not in drupal module load system.


I'm going to try few more tricks :) and I write back when I find out
something interesting.









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20090107/fa4fe505/attachment-0001.htm