"Drupal is a very resource hungry web application ..."

Questions:

- What modules do you have enabled? Any of them contributed?
- How many users/visits do you expect per day?
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

My shared host provider also has concerns also has concerns about Drupal. Many of the host providers do not like the fact that Druapl requires the user to have the MySQL privilege to LOCK TABLES. A number of Drupal developers will tell you there is no risk for host providers to grant users the right to LOCK TABLES.

I originally bought the developers argument, but now I'm not so certain. Even the MySQL reference manual says that LOCK TABLES is for server administration and not something usually given for the user (within the context of tables). The reference manual also indicates that:

Normally, you do not need to lock tables, because all single UPDATE statements are atomic; no other thread can interfere with any other currently executing SQL statement... You can avoid using LOCK TABLES in many cases by using relative updates (UPDATE customer SET value=value+new_value) or the LAST_INSERT_ID() function, See Section 1.8.5.3, “Transactions and Atomic Operations”.

You can also avoid locking tables in some cases by using the user-level advisory lock functions GET_LOCK() and RELEASE_LOCK(). These locks are saved in a hash table in the server and implemented with pthread_mutex_lock() and pthread_mutex_unlock() for high speed. See Section 12.9.4, “Miscellaneous Functions”.

With host providers who have concerns with how Drupal's requirements of server admin privileges you really can't use the reference manual to assist in getting you those rights. Also, Drupal 4.7 is also likely to require CREATE TEMPORARY TABLES...another server admin privilege. All I can say is it's a shame that the developers can't come up with a better solution that would please more host providers. It's a shame, because I love Drupal but will likely only be using it on the corporate Intranet where I have control over the servers.

-Bryan

References:
http://dev.mysql.com/doc/refman/5.0/en/privileges-provided.html
http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html

In my experience, there was no complaints from hosting companies I used for my Drupal sites. I have been running 3 sites on Drupal for 2 years, and never was there an issue of performance.

I used two hosting companies which are by no means high end, and all of them had the LOCK TABLE privilege. None of them complained about Drupal being resource hungry.

One client was hosting on DreamHost. They refused to allow some PHP parameters to prevent PHPSESSID in URLs. They told the client to compile PHP as a CGI and used it as such. When I did this for them, DreamHost turned around and complained about CPU usage being high. This is a busy site. Details on this are here.

Going back to PHP as an Apache module seems to make things better.

Personally, I would stay away from hosts who:
a) force you to CGI, then complain about CPU usage
b) Disallow LOCK TABLE
c) Do not allow you to override parameters for PHPSESSID and such
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com