I have several hundreds of modules in my various D6 Drupal installations so that when I need any of them I don't have to download them first - I just go to /admin/build/modules and switch on what I want.
Now, the problem is that that list of modules takes ages so long to load that the work becomes inefficient. I also suspect that Drupal might be slowed down in general because it has all these folders in the modules directory - though I am not sure how often they are scanned.
I am inclined to make sure all inactive modules are uninstalled and then move all their folders one by one away from the live machine. Except, that might take many hours, because the module folders often do not correspond exactly to their module names (e.g. module "CCK Privacy" is in folder "privacy"), and because some modules might actually be in subdirectories in cases where one project ships several modules at once.
This problem is further confounded in case of multisites, where some modules might be inactive for one of the sites, but they need to be in the directory because some of the other sites use them.
I have been thinking about the best solution to this for a long time now, but without any really good ideas, so I would like to ask the others here in the high performance group how are you balancing the need for a quick overview of available modules vs bloating of the modules directory and admin page. I know that some of you will want to say "drush is your friend" - but is it really? It allows installing and uninstalling a module from d.o. in a quick way, but it does not provide a nice overview list of modules I have hand-picked before for possible future use. Or should I better keep all the modules that I picked and consider using or testing off site in some text editor -- is that the best way?
I'll be thankful to any examples of how do others deal with such issues and needs.
Comments
I thought multisites allow
I thought multisites allow you to store and enable modules within the site. For example:
sites/vacilando.com/modules
sites/example.com/modules
A possible multsite approach is, go to sites/ then do: ls -R | grep {regexp here?}/modules > mymodules.txt then take a look at your inactive and active modules list. drush pml | grep works as well.
You mean "drush pm-list" or
You mean "drush pm-list" or "drush sm"?
I'm using drush 4.0, and
I'm using drush 4.0, and wanted to pipe the pml list to ms excel for sorting and filtering. Some of the commonly used drush commands are available with a shorter command name - drush pm-list is drush pml. Just the "drush" command by itself will print the available commands along with the shorter forms. I think drush commands go through bootstrap. You can view this fixed drush issue if interested: http://drupal.org/node/1023774
API
drupal_system_listing only gets called on cache rebuilds for the most part
This. This is really a
This. This is really a non-issue for normal operation of a site. Don't worry about it.
The Boise Drupal Guy!
I have several hundreds of
Does that really make your life easier? I ask because I've thought about doing something similar in the past but never did because it seemed that it'd be too much of a hassle for too little actual productivity increase.
I think it would not make
I think it would not make things easier since they will become out of date rather quickly.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
If you want to use chmod,
If you want to use chmod, drupal will still load the modules page, but without an entry of any folders that are denied by chmod (hopefully disabled beforehand.. ha), thus the page can load quicker. Rss can be used with a drupal install. Keep a rss reader list for all the modules you want to track, and then you can get an idea of your disabled modules that need updating by compare ls -l against your rss reader list of modules. Obviously, views or some other type of coding, where smaller statements and less of a footprint to d.o is a better solution - the update status page and native drupal update can take a long time.
This will do
but use with care. Requires drush:
drush pml | grep -i 'not installed' | cut -d '(' -f 2 | cut -d ')' -f 1 | xargs -I %c find sites/all/ -name %c -exec rm -fr {} \;This will remove all dirs of unactive modules. Note that you should uninstall any module before removing it, since otherwise you'll leave DB tables, columns, or rows lying around that were used by the modules that you removed.
Nice one Perusio. Thanks
Nice one Perusio.
Thanks
What does the group points
What does the group points do? =) Learned a lot of good commands perusio, thanks.
Me too
http://all.DruMI.org (= dir listing of /sites/all dir's of another site) => Hundreds of modules and Drupal core often crashes, although its only a very low traffic test-site (shared hoster with cpu throttling).
The way Drupal handles modules, should be changed a little. I'm not technically into Drupal/PHP etc. But some suggestions:
As mikeytown2 having pointed
As mikeytown2 having pointed out, the disabled modules in most case don't have any negative on the site performance, but only in admin page.
If you have a lot of modules, you'll need a lot of RAM. Most shared hosts limit PHP max memory limit to less than 128 MB (yes, I know for many, it's much less than that, like 64 MB). That's simply not enough. I have 384 MB limit, 200+ modules (120 enabled, including cores), and it's quite fast.
And the last: don't use throttle, it's not very useful in this case.
Hmm
That could happen because:
As per 1, you can disable the update status module. That will speed up considerably your administrative tasks, namely after enabling a module you don't have to wait for drupal to check for updates. Of course you're out of the security update loop now. Benefit/cost analysis applies.
As per 2, there are lot of possibilities. Also benefit/cost analysis applies.
Your PHP processing pipeline
People like to beat-up on mod_php a lot. But any proper benchmark that I've even seen show the differences between the various alternatives to be negligible. For example Rasmus' Drupalcon Paris presentation. I highly highly doubt that changing how your web server runs PHP is going to affect the performance of the update status or modules pages.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Negligible in what terms?
Memory usage?
CPU usage?
I've nowhere said that mod_php and Apache have anything to do with update status. That's a network issue like I wrote above.
As for the modules admin page we'll have to compare it. I propose the following scenario:
Apache with mod_php.
Nginx with FastCGI.
of course memory and CPU usage must be taken in to account since resources aren't free.
Do you know if the slides for
Do you know if the slides for that presentation at DC paris are up anywhere?