Unless you have a caching server in front of RR you are still going to get blasted by slow connections, hung connections, h4x0rz, search engine robots, and the weight of your own application.
FastCGI only helps if you have a separate caching http server sitting between your application server and the 'net, because otherwise RR is still building all the dynamic content by itself, on the fly, in response to all of the requests. How many RR server farms are you aware of? Do they integrate tightly and load balance without a lot of intervention? This means you have another layer of overhead that you have to install, maintain and develop for. I think this argument is sort of like the current generation of AJAX programmers who think that Perl/Python/PHP/Ruby is an acceptable and reasonable long-term implementation plan. It isn't because the learning curve is too steep and the deployment tasks too complex. -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
