If you only have 65 threads available, it also means that only 65 user requests can get served by AOLserver. In theory, if you have page response times of less than 1 sec, 65 threads can potentially serve many more users (at least up to 150-200 users). The problem that kicks in, though, is that you have response times of >1 min.
So in an extreme case, you will have 65 users waiting for the page to load, another 35 users in the wait queue (maxconnections = 100) and the remaining 50+ users getting an "Unable to connect to _your server_".
You will have to find out what the primary reason for the huge response times are. Does the application wait to get a free db handle, does it wait for queries to complete, does the RP take a long time, or is it maybe just the browser waiting for a connection to the AOLserver? If you have developer-support installed, it will probably give you some valuable data.
Next step depending on where the problems is might include:
- increase maxthreads (I believe you can easily increase it to 80+ on such a big server)
- optimize pages/queries
- put as much data as possible into cache
We have seen similar problems for AIESEC, and I can tell you that the solution was mostly in application tuning, assuming you have the right database setup. The biggest performance impacts we have seen are related to the portal system and the permissioning system which take up a lot of database time. We are currently upgrading to OpenACS5/.LRN2 but I am still sure that those will be the most expensive pages/queries on the system.
