This is pretty standard performance. The K5 server can do upwards of 8 or 9 requests/second, using concurrency, but if you cut it down to a single apache process, it'll only plow through maybe 1-2 requests per second.
The main reason for this is the amount of DB communication that goes on behind the scenes. Scoop caches a lot of stuff (you should see a noticeable speedup if you run ab a second time, for example), but there's still a lot of DB calling that goes on for each request. We really do need to improve the speed of this.
I'm starting to think that the way the Scoop DB layer works needs to be overhauled. There's no easy way to cache data, because we deal with statement handles directly, instead of returned data blocks. Being able to cache all the results from a particular query would speed things up some more. Also, being able to run multiple queries with ? placeholders would help, as a bunch of the repetitive queries could be sped up if they only had to be prepared once.
Also, the way you set up your apache can make a big difference. See the mod_perl guide for info on how to set up a dual-server accelerating proxy type situation. General mod_perl speed issues are here.
So, raw blinding speed is not a major feature of Scoop right now, I'm sorry to say. We've been concentrating much more on features and stability so far. While it may not pump out the pages like a static site, I can assure you that scoop is more than capable of dealing with a slashdotting, or running a site that normally serves 70,000 pages a day. That is, it's kind of the Solaris of weblogs: not the fastest, but very stable under load.
