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

[Zyumbilev, Peter]

Hi Roger,

I still wonder why don't you do this:

1. Downloads and install from source apache & php 5.3. There are penty
of tutorials how to do this. Compile only php modules you need.(!)

2. Install in /usr/local/ (It goes there by default)

3. Modify firewall to allow port 8080

4. Edit httpd.conf of the newly compiled Apache so you have correct
DocumentRoot and make it listen 8080.

5. Start the new Apache on 8080

6. Check how site behaves on port 80 and port 8080.

A) If it is better on 8080  shut down primary Apache, and change teh
port of the new one on 80.

B) If it is the same, check database - run check and repair mysql tables
- might be broken indexes or something.


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>
>