Deprecated - Performance and scalability

I apologize if this is covered somewhere. I've spent a lot of this weekend trying out Drupal and looking at the forums.

My background is in prgramming and admining large sites - up to tens of thousands of pageviews an hour, and spikes that even dwarf that. Typically there is some amount of mostly forward facing content which accounts for 95% of the traffic (the main page and perhaps a few secondary pages), and then possibly more advanced content such as a forum, etc. Not unlike the Drupal.org site itself.

"The birth, death, (and hopefully rebirth)" thread kind of scared me.

I guess my default approach would be to serve out the common pages as static html files, which could be updated when content is changed or via a cron job. I see a few modules doing somewhat similiar things - in particular "boost" (http://drupal.org/project/boost) - however I couldn't find one that really seemed to have a lot of development momentum.

Drupal 7 is mentioned in http://drupal.org/gophp5. Time to start a Drupal wish list for 7.

For performance, I would start with a change to the node module to reduce the database overhead from revisions. Why does noad_load always join to revisions? We could put the current data in the node and make the revision table a record of other revisions. noad_load would have one less join.

I keep Getting This E-MAIL Sent automatic I guess, I DO HAVE CRON ENABLED
Anyone know how i can take care of this, I have read every post i can find none seem to compare with this.from "gangthree@gmail.com" hide details 10:09 pm (5 hours ago)
reply-to gangthree@gmail.com
to gangthree@gmail.com
date Jul 2, 2007 10:09 PM

Ok, so my website was working all fine and dandy until one night, it starts freaking out every time I try and go to it. When I try to go to it, it gives me a little window saying "You have chosen to open 'application/x-httpd-php'", as if I'm trying to download something. I'm not sure why. But right before it started doing this, I added a slideshow to a page in HTML format. I've used the website and the slideshows before, and nothing like this has ever happened, so I dunno.

Help, please?

That's the question:

Is it at all possible to tweak drupal or the environment in which a drupal site functions, in a way that memory usage problems could be overcome within a shared cpanel environment? (searching the drupal site will show many others who encountered the same or similar issues)

This is a question i ask myself and a log as to what i have found so far in tweaking my sites, that are currently seeing a lot of 500error page not found because of premature end of file errors, as a direct result of too much memory usage (more then 16mb).

The hosting company only gives 16mb of RAM per account within packages as normal hosting, reseller hosting and fail-over hosting. They would be between $5 - $30 a month. To increase RAM i would have to go with a form of dedicated hosting with dollar amounts that are beyond that mentioned earlier.

The site causing the problem has around 150 members with maybe 40 daily active members logging in and reading pages and posting comments and some nodes (around 1 blog and maybe 4 comments a day).
The extra modules are maybe around 20, including pathauto, within drupal 5+.

I've been searching drupal.org and found the following posts concerning memory usage problems:
- fatal memory Memory Problem

We got MySQL logging slow queries, and we found that one of the most offending queries come from the user.module. Basically, the function user_load() in user.module constructs queries generically and may not always use uid (primary key) or indexed columns for look up. Here are some combinations of WHERE clauses used by user_load():

* WHERE uid = # - this one is the best as it uses the primary key.
* WHERE mail = '***' - this one results in table scan unless we add index for the mail column
* WHERE pass = '***' - similar to mail above, resulting in scanning the table. However, we don't look up using only password without other fields.
* WHERE LOWER(name) = LOWER('***') - we thought this would use mysql index, but instead it doesn't. This query results in a table scan. Upon careful examination. The problem is because of using LOWER(). When we have run LOWER() (or even UPPER()) on an indexing column, we effectively disable the use of the index because to correctly match, MySQL has to convert the name to lower string before comparison.
* WHERE LOWER(mail) = LOWER('**@**') - same situation as above with name but easier to solve as we can always save email address in lower cases.