I'm curious that discussion comes back to how many modules are installed. Does this imply that significant commercial users are also locked in to a few core modules? We have only the modules we need, and some additional ones which overcome inequities in other modules, like Nat needed to overcome a Workbench-Taxonomy access problem that shouldn't exist in the first place.
41 modules in all, most of which are base Drupal, like Views, Pathauto, token, etc. Users don't have choice on prerequisite modules so I am at a loss to understand the number of modules as a memory issue. I would mention though that a php dev working with us a while ago pointed out how badly some modules are written.
Modules, nothing more than plain text files, concatenate into a homogeneous lump, they don't add much to the over all size of the Drupal operating system, but how they handle and release memory is critical and if the number of modules assertion is true that "many modules make Drupal collapse", then perhaps someone could look into module interactions more closely.
We are in 2013-4 era, with increasingly complex hardware and technologies, Should Drupal easily handle dozens even hundreds of additional modules?
Sad part for us is that I have to set up the site to create newsletters and that means even more modules and possibly additional views. Is this to mean that Drupal is about to have more problems?
Thanks Roger
Every module is coded in a different way. While some can be benign, others might be less so. Some modules create additional load because they force pages to be re-rendered, or for permissions to be re-checked and so forth. This is a community-project, which means lots of free great code, but also not everything is coded perfectly at all times, since everyone is contributing in an open source fashion.
Each module that is activated also creates some additional function calls, depending on the functions found, those functions will either run once and be cached, or be perpetually accessed every time their hook_ is called.
Is adding one more hook_ a problem? Not inherently, but clearly the more you add, the more calls need to be made.
If you want a system that can handle hundreds of modules, each with potentially tens of functions, each of which is doing a calculation then surely that increases your server's stress? There is nothing magic about any CMS, it is, as you say, just a bunch of PHP code.
An optimal system needs careful consideration. If you want a site like facebook, where you are dealing with tremendous stress considerations, you generally just build the site up from scratch. No CMS, you put all the parts together, with the absolute zero-line that anything non-essential is scrapped. If you have the budget to build your site from the ground-up, you just don't bother with any CMS and build your own (or use an extremely lightweight framework as your base point).
Drupal gives you a lot out of the box, not many CMS's can crunch out full blown applications with such flexibility and extensibility, but flexibility comes with a price. Optimizing Drupal sometimes involves stripping things away, researching how things were done by others, and improving the code that others have made.
Your question and concern is extremely general, so it is hard to give you anything concrete in return.
Can you run a complex application on Drupal? Absolutely Can you run a site that has an extremely fast response time? Most definitely Can Drupal be used on a website that has high traffic, sometimes with burst traffic intervals? For sure can I get a high performant site, by installing any module I find on the net, keeping it on, and just expect that clicking "setup" is enough to achieve high performance, and high speed? Doubtful…
You need to be good at web development to be good at performance and optimization. It is a very complex subject, and many solutions, depending on need, can bring you beyond drupal, to things like memcache / apache / mysql optimization.
Drupal gives you a giant flexible application building API/environment. You then need to take care of it to make sure it retains high performance.
Hope this helps!
-- Info Razor Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Friday, April 5, 2013 at 4:39 PM, Roger wrote:
I'm curious that discussion comes back to how many modules are installed. Does this imply that significant commercial users are also locked in to a few core modules? We have only the modules we need, and some additional ones which overcome inequities in other modules, like Nat needed to overcome a Workbench-Taxonomy access problem that shouldn't exist in the first place.
41 modules in all, most of which are base Drupal, like Views, Pathauto, token, etc. Users don't have choice on prerequisite modules so I am at a loss to understand the number of modules as a memory issue. I would mention though that a php dev working with us a while ago pointed out how badly some modules are written.
Modules, nothing more than plain text files, concatenate into a homogeneous lump, they don't add much to the over all size of the Drupal operating system, but how they handle and release memory is critical and if the number of modules assertion is true that "many modules make Drupal collapse", then perhaps someone could look into module interactions more closely.
We are in 2013-4 era, with increasingly complex hardware and technologies, Should Drupal easily handle dozens even hundreds of additional modules?
Sad part for us is that I have to set up the site to create newsletters and that means even more modules and possibly additional views. Is this to mean that Drupal is about to have more problems?
Thanks Roger
-- [ Drupal support list | http://lists.drupal.org/ ]
On 06/04/13 07:39, Roger wrote:
I'm curious that discussion comes back to how many modules are installed. Does this imply that significant commercial users are also locked in to a few core modules? We have only the modules we need, and some additional ones which overcome inequities in other modules, like Nat needed to overcome a Workbench-Taxonomy access problem that shouldn't exist in the first place.
This sounds like a response to what I said.
I have been running drush, and adjusting its parameters such as modules & themes choices, and evaluating the consequences.
I've no been adding content, well perhaps one tiny article, roles or more than one user.
I got an out of memory problem on one combination, and only when evaluating Jackson, and that happened only in 7.22.
In my case I rule out everything I did as a cause of the problem, because I did nothing that is likely to produce the problem.
I am running on CentOS 6 with all the current updates, so it's fair to expect the problem isn't in PHP or Apache. My site-wide memory setting is 128 mbytes.
That leaves Drupal, probably the Jackson theme.
I don't think my problem is related to yours, but I don't really know much about yours.
However,
Jackson runs a slide show. Your problem is connected, if I recall correctly, with processing images.