I'm not sure why. I even have PHP-APC and memcached installed. I will greatly appreciate it if some can help me take a look. Thanks.

Do you have drupal caching enabled, page compression, javascript and css optimization and how many drupal modules do you have enabled?

You should also check out http://mysqltuner.pl maybe your mysql queries aren't being cached or your key buffer is too small.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

I have drupal caching, page compression, javascript and css optimization enabled.

I do have a lot of modules, at least 130. I will check out the http://mysqltuner.pl link. Thanks.

..130 modules yeah that's going to be slow, delete say...100 of them.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Or it could be one or two inefficiently written modules.

How do you find which modules are inefficient?

Make sure it's not a front end problem using firebug or webpagetest.org.

Make sure that APC is working correctly using the apc.php page. If, for example, your APC cache is too small, then the system is constantly flushing from the cache and inserting new code, so it's even worse than if there was no opcode cache at all. Check for cache full/cache flush/fragmentation.

Install the devel module. Enable the page timer and query info. That will show page execution time and mysql query time on the bottom of each page. Navigate around to see if it's only certain pages with certain blocks that are slow. Maybe it'll be obvious that the problem only exists on certain pages that contain a specific block or query.

If the delay is mostly in mysql time then enable the query log and check out which queries are running long. Trace them back to particular views or modules based on the query. It's happened before that a less popular module works fine for smaller sites but horribly on larger sites because of the way queries are written. Or you made a view that is unnecessarily complex. Or you have a very complex view that doesn't change more than once a day so you can enable views caching on it.

If the delay is mostly in page execution time and the mysql time is only a small part of it, then you may need to do profiling. That involves installing either xdebug and webgrind or my preference is the XHprof extension with the sample web interface. Devel has XHprof support built in. If you're on Ubuntu you can use my ppa to add the XHprof extension through apt. See http://groups.drupal.org/node/82889

Then start sorting function calls looking for the ones taking up most of the time and tracing them back to a specific module.

Since this is a linode board, I assume you're on a linode so having a crappy host shouldn't be the problem.

Thank you brianmercer for the tips. I'm new at this linux thing so I'm a little confused about a lot of things. I'm on Debian Lenny. Would you please help me take a look? I will pay for your time. Please send me a note at diztost3 [at] yahoo.com. Thanks.

If you're still on Drupal 6 (and you haven't hacked core, ahem) you should definitely take a look at http://pressflow.org/ a high-performance fork of Drupal.

If you get a lot of anonymous traffic, Boost is a great module for caching on D6. It basically caches all pages in html.

You can let the module crawl the pages so they're cached before someone visits them.