I am doing performance optimization for a project. This project has total 269 modules, in this 181 are contributed modules, 56 are the features/panels export module. Remaining are the custom developed modules.
With these many number of modules enabled, the apache process is taking memory of around 189 - 250 MB of RAM.
I decided to remove all unwanted modules. Now 56 exported modules I wanted to disable and finally remove them, because these are already available on the database. These many export modules added because of distributed team and to make the update process of Dev->stag->Production.
The problem is when I directly disable the feature export modules the content types, views are getting deleted. Now i want to disable these modules without the content getting deleted from the database. Does any one face this kind of problems? How can I disable feature export modules without deleting content from database?
Comments
Too high
Not a direct answer to your question, but very much related ...
269 is the highest number of modules I have seen enabled on a site.
One thing about features is that a .module file has nothing but an include of a .inc file, and that means two disk access operations are performed.
One thing you can do is manually move the .inc to the .module, and it will cut down 56 file accesses from each page load. Try it and measure it first, and see if there is tangible benefits, and if so, you can write a script to do it automatically when moving from staging to production, so you don't change how features are developed.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Indeed
If you no longer need to develop on the features, you can also combine them all into one module, which would remove a lot of hook operation overhead.
IMHO storing them in the database is not the best idea. It's going to inevitably cause some issues.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
I have a solution for
I have a solution for you:
Export via Briefcase first.
Briefcase is a little known module, which also once was marked as duplicate of features (which it is of course NOT), which saved my day more than once. And helped me in a very tricky deployment by allowing me to export domain specific menus ...
Briefcase is a pure importer / exporter for CTools Based Objects or Views.
It is very easy to use, too.
drush briefcase-export views
drush briefcase-import views
drush briefcase-export cck
drush briefcase-import cck
or with names:
drush briefcase-export views my_view
So for your scenario you would do:
$ drush briefcase-export views
Do you really want to export all views? yes
$ drush briefcase-export cck
Do you really want to export all content types? yes
$ drush dis features
$ drush briefcase-import views
Do you really want to import all views? yes
$ drush briefcase-import cck
Do you really want to import all content types? yes
I hope that helps.
Best Wishes,
Fabian
PS: One caveat: On multilanguage sites you need to make sure english is your default or force $language to NULL before exporting by patching briefcase. But that was the only issue, I ever had with that.
APC, profiling, patches
Make sure you have APC enabled, and enough memory allocated to fit all the PHP files in memory (you may not with 269 modules).
Profile the site with xhprof to get a better idea of where the memory is actually being spent - be careful of places like the theme registry (especially with lightbox2 module), schema cache, CCK content type/field info cache, and default views (especially, if you have lots of default views, but some views are only in the database, there is a serious memory issue).
I'm assuming this is a D6 site - there are a few patches around in the issue queues that improve memory usage of various modules, start with http://drupal.org/project/issues/search/?issue_tags=memory
Try drush_em
If you're a drush fan you can try drush_em. Be careful not to let it revert which is a default setting. It just clears all the stuff exported from the DB. Add something like this to your
drushrc.php:<?php// For drush em-dump don't revert ever.
$command_specific['em-dump']['e'] = TRUE;
?>