Remember that MySQL doesn't implement subselects and a variety of other things that simplify building One Really Big Query to build page contents (vs. A Bunch Of Little Queries). MySQL is also reputed to suck on joins of several tables.
So Slashdot may need to process a lot more MySQL queries than Jerry has in mind, each with its parsing and optimizing overhead. I don't know this for sure, but it is something to keep in mind.
Slashdot's pages are quite complex, with the ads that are served, and the various summary boxes (heavily cached I'm sure) that run in the margins.
As to whether or not OpenACS is reasonable for a slashdot volume site, with all that hardware a highly customized version of OpenACS 3.2.5 could, I'm sure. "highly customized" would include having the AOLserver front-ends cache the front page and Q&A threads for several seconds (or more?) just as slashdot does now. The toolkit isn't set up to do this out-of-the-box but ns_cache and util_memoize would make it quite simple to do so.
[Open]ACS 4 is another matter altogether with the request processor and more complex permissions model. Thus our need to do more performance testing once we feel like we've made sufficient progress in our speed-up efforts. Until we see some real numbers I'm not crawlin' out on no limb, uh-uh.
One interesting datapoint I do have: I can create about four bboard posts a second on my PIII 500 with its 5400 RPM IDE drive (the one that causes a "kernel panic" in DMA mode, therefore it is running in high-overhead PIO mode). A 15K SCSI disk would quite easily double this I think, given the ugly (but free and big for its age) disk. A fast dual-processor system would probably double throughput again, getting us up to 16 bboard posts inserted a second. It's not hard to imagine the combination getting above 20 bboard posts inserted a second, either. This is OpenACS 4. This hints at reasonable performance - but it is no more than a hint and I'm well aware of it...
