[support] Fed up with Drupal 7 ... Desperately.....modules.etc

[Zyumbilev, Peter]

You can safely increase memory limit to much higher value.

The price of a block of RAM is very small. Increase php memory limit to
512Mb and see how it goes. That might the simplest solution to try :-)

Peter

On 07/04/2013 03:08, Roger wrote:
> Thank you for this in depth discussion it is much appreciated, and yes, 
> I do appreciate the ease with which Drupal "sets up" a full blown site.
> I also very much appreciate the highly professional way people respond, 
> no flame wars, no ridicule, just patient insightful information. Thank you.
> 
> My observations to date:
> -- Our server runs Centos 6 and php 5.3
> -- Drupal is a great system but can suffer from less than optimal module 
> coding as explained below.
> -- Some sites have 60 and more modules and work flawlessly.
> -- Our site works flawlessly for the most part.
> -- We have 41 modules soon to be about 45ish when I start the newsletter 
> system so number of modules, in our case,  is not a problem because most 
> are not used in normal operation or called infrequently but are still 
> required.
> -- We have a very minimal site with very low demand from users, minimal 
> demand on modules, minimal calls on database (until I get the newsletter 
> system working) and few display calls, little of the below discussion 
> relates to our requirements.
> -- Add Content Type is still a problem, it seems to unexpectedly fail.
> -- Based on  a previous response,  adding a Content Type, seems to have 
> much broader issues with far greater overhead than I first understood.
> -- Apart from altering php memory_limit, which works sometimes but has 
> wider implications for the whole site,  there is no definitive answer to 
> this Add Content Type problem.
> --There seems to be no pressing need to have greater than 128M allocated 
> to PHP. Our ISP support team advise against increasing above 128M.
> 
> Conclusion:
> It seems that Add Content Type puts outrageously heavy demand on a system.
> Why it has 17 includes unrelated to creating a content type,
> Calls 18 scripts, all but node/content_types, completely unrelated and 
> unnecessary at this point,
> a huge jQuery that has nothing at all to do with anything,
> irrelevant menu lists that are switched off, not in use, or not in the 
> least related to this display,
> I am not sure.
> 
> Reading about Ruby on Rails and separating out the business logic from 
> data and  views. Looking at the underlying code for Drupal Add Content 
> Type it seems there is a need to separate out much of the business 
> logic. But I do not know if this can be done with PHP.
> 
> As below, optimising Drupal means stripping things away, but when faced 
> with this, stripping can't help much.
> Roger
> 
> <snip>
> 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)
> </snip>
>