In OpenACS 4 we know that the request processor is a bottleneck because it was a known bottleneck in aD's ACS 4 classic.
I'm a bit concerned about the fact that Postgres isn't working much in
Gilbert's 7 page/sec scenario. Gilbert - you mention that the two CPUs are now getting AOLserver threads assigned (good observation on the userlands threads issue, that really sucks). Are they both mostly
pegged?
If there's idle CPU time in there and if PG's not terribly busy and if
you've allocated enough shared buffer space to PG and disk I/O (or kernal time for shuffling data back-and-forth between the kernel cache and the PG shared buffer cache) then you've got more work to do. Perhaps you don't have enough db connections allocated for each pool and threads are stalling waiting for connectiosn.
On the other hand, if both CPUs are pegged then toss that theory out the window.
Another potential bottleneck in OpeNACS 4 is, of cousre, the query dispatcher. I haven't followed Ben's work in awhile and don't know if
query mapping's being cached at the moment or not.
The fact that only 17 vanilla html pages/sec are being delivered points to the request processor. I'd hope we could avoid writing it in C but it is clear we need to hammer on that to make it more efficient one way or another.
