My main point was that Nima has to find out what the primary reasons for his extremely slow page response times are, possibly using developer support (and AOLserver stats as Don mentioned).
The comments about the database were mainly to illustrate that application tuning was the most crucial thing for us. Even though we have a strong quad-Opteron database server which is usually about 50-70% idle and the load rarely goes over 1.5 or 2, we do have some pages that take a very long time to execute because there are e.g. many huge tables being joined and/or very many permission checks on those pages. Btw, when I mentioned the portal system, I didn't mean the portal system as such but rather some portlets which run very expensive queries.
So based on our experience, I would support what Dave has suspected earlier: Long-running queries can result in slow response times even though the load on the db server is low. And this in turn can block available AOLserver threads which will mainly become a problem during peak times with many concurrent users.
I didn't mean to say, though, that this or any other reason is causing all the trouble. That, as mentioned, needs more careful analysis of the entire system.