So, we have a large, complex Drupal 6 site, which has lots of secret sauce and magic glue making it work.
Where we can, we've contributed modules back and made them generic, but we still have 30 or so custom modules to keep it working the way we need it to. Each module (in most cases) has a specific function e.g. our hook alters for the notification system.
We are doing a huge code review at the moment and looking at improvements we can make. One thing suggested is to merge the large number of modules into a few smaller master modules, with lots of include files. We would, perhaps group by general site area e.g. "community", "admin" and "messaging", instead of specific modules per functionality.
So the questions are :
1) Is the effort in doing this worth it - will it speed up the site?
- What module grouping would you recommend ?
- by site area ("community", "admin", "upload")
- by hook ("form", "node", "user", "theme")
- everything in one module
- something else?
2) What naming conventions should we use for the include files to keep the codebase sane?
3) Am i right in assuming the goal should be tiny .module file with includes per hook / menu / area.
This is a X-Post from drupal.stackexchange.com : http:///questions/14588/30-custom-small-modules-vs-5-very-large-custom-m...
Comments
Is the effort in doing this
It sounds like you don't really know what your bottleneck is. This restructuring will likely have very little impact on performance, but it may make things easier for you to maintain. If you do decide to restructure I would recommend splitting up along "site features" (blog, image galleries, etc.).
But if performance is your concern you first have to diagnose the problem before you attempt surgery.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
How do I get off this thread?
How do I get off this thread? I didn't even subscribe to it knowingly in the first place!
If you are part of the groups
If you are part of the groups the poster tagged this thread with, you will get notifications!
If you look at the code for
If you look at the code for module_invoke_all:
http://api.drupal.org/api/drupal/includes--module.inc/function/module_in...
You'll see there's a tiny, miniscule, trace performance gain by having a monolithic module isntead of a number of different ones.
It is honestly not worth the effort, the gain would be measured in nanoseconds. Spend your time making the code idotmatic and maintainable.
If you're looking for performance improvements then invest in some caching (varnish, memcache, boost, drupal_static) or work on removing modules instead of coalescing them (replace pannels with traditional templates, hand write SQL instead of views, make sure devel and views UI are off on the live site).
http://www.linkedin.com/in/linuxwizard
The number of files doesn't
The number of files doesn't have any real impact on performance but the number of hooks does.
For example having all the code in mymodule_nodeapi() will be faster than having the code in mymodule1_nodeapi(), mymodule2_nodeapi(), mymodule3_nodeapi() and mymodule4_nodeapi()
But totally unmaintainable.
But totally unmaintainable. I'm highly opposed to sacrificing maintainability for performance.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Maintainability and
Maintainability and performance are generally opposite metrics that you have to strike a balance about; that's why engineering is not a science but a series of judgment calls.
Consolidating modules may or may not be a good thing, sometimes you do have fragmented code that was developed piecemeal and needs consolidation and sometimes you don't.
You need to keep an eye on readability, maintainability and performance and strike a good balance.
An example
This Pdf presentation has very good findings regarding performance on a Drupal 6 site:
2bits.com/drupal-performance/presentation-34-million-page-views-day-92-million-month-one-server-and-drupal.html
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
Yes, I have seen it before,
Yes, I have seen it before, agree 100% on what they say. Anybody interested in performance should see it and apply the concepts.
Many thanks for the replies
Many thanks for the replies thus far.
Yes, this is more about "best practice" than a specific performance issue. We already have caching, varnish etc. Part of the review will to be drop panels and move to display suite. And we will also be doing more traditional tuning, but this issue of "lots of modules" was one we couldn't find any concreate good information on.
If the gains are generally accepted to be tiny and already best practice, we may well just keep its as is, a "functional" split, and use the time in code re-view / refactoring / documenting.
Two tier approach
We had a similar project: refactoring a client code base, we ended up having a two tier approach:
Tier one: by hook – holding no business logic
Tier two: business logic – in .inc files or modules gets triggered by tier one.
This ended up being easy to maintain and also solved many of the technical issue our client had, as it was easy to control the sequencing of events. Before we made this change the system had code that got triggered more then once, leading to both performance and errors on the site.
I think we are going to split
I think we are going to split based on site area / business logic mostly. Where there is a lot of cross over between two business logic areas, like two user groups (signup, profiles, newsletters etc) we will create a generic "custom_user" module.
Current estimates look like a 70% reduction in number of modules and hopefully much more readable code as its now split by business logic, instead of functionality.
split by usecase
check this video http://www.archive.org/details/ThisCodeStinks
from archive.org:
This Code Stinks! - Larry Garfield
"Code smell" refers to hints and patterns within code that can be a tip off that something is wrong. Learning to recognize code smells is a critical skill in software engineering. If you can sniff out a bad code smell early, you can eliminate a bugs before they even happen. If not, you may find yourself needing to rip out large swaths of code (not to mention your hair) because you ran into a wall, muttering to yourself "I knew that was too hacky an approach..." Recognizing code smells is also an...
Keywords: Drupal; Badcamp; Badcamp2011
to weigh in about module dev
to weigh in about module dev structure. Elms previous version a4 had 2 or 3 mega modules. These coils only be used in elms and were a collection of way too many things. As of the last release those mega projects were abstracted into features and other also were developed. The flexibility has lead to 30 projects being preparedness a result of elms but now many of those projects can go into benefiting other drupal systems. I think its definitely a sustainability vs flex issue. If you are thinking ultra long term, its worth the short term performance vitamin extra hook / file calls to be more transparently dev.
if I wasn't contributing things back though I'd probably have far less modules :-)
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/