For all the magazine talk about everybody needing something capable of sustaining some ridiculous number of page hits/sec, I don't personally know anyone operating a site that Zope couldn't keep up with. If you're Amazon.com, maybe you'd look into ZEO or something, but if you're putting up a Linux user group page or something along those lines, Zope's probably going to frequently be tapping its fingers waiting for the next request.
All it takes is some credit card processing over SSL with Apache and you will definitely need multiple servers. As a benchmark, on a dual processor 450Mhz webserver with lots of RAM and a rainbow SSL card, running Linux 2.2.x kernel and a recent version of apache, we never saw more than 150 transactions/second with normal requests to static objects in apache. This was on a platform that can do over 1000 TPS without SSL. The overhead for SSL is huge. If you also include the length of most CC processing transactions, you also have to deal with requests that last 20 seconds instead of .5 seconds. This causes very intensive resource utilization. Now translate those numbers to Zope. Zope starts out with no more than 150 TPS on the same hardware. Now throw in SSL and it probably drops to 20 or 30 TPS. Add in 20 second long transactions, especially with our friend, the python interpreter lock, and you run into real performance issues. However, if you have a machine that is dedicated to running the credit card processing, you can build the entire transaction in zope, but then have the final submit button link to a credit card processing box that is just running straight apache. I should imagine that you would have reasonable performance numbers that way. If your site only processes 1 or 2 credit cards per second, you probably will have no problem, regardless of your solution. I had the joy if building a system that could process 1000 Credit cards/second, and it was not fun (no we didn't use zope, I didn't know about it yet). Of course, it turned out that Visa themselves only process about 4000 cards/second, so we had a few spare cycles in the end ;-) --sam