Greetings. >> So mod_perl has a slight speed edge over fastcgi (which is overthrottled a >> little with four servers).
>Really? Maybe this is because multi-process handling isn't as fast on NT. >Does it change much if you vary the number of servers? Well, I am getting a little wary of the numbers I get with ab, and on the significance of the -c[oncurrency] switch. In fact, by using different logins on the same client machine (rather than blasting the server from a single login), I get consistently lower request per second numbers than I previously posted (in the 7 rps for mod_perl, 5rps for fastcgi). Besides, as I am testing a single CPU load machine against a single CPU server machine, I am sort of measuring the ratio of the respective process/thread/whatever switching efficiency, whereas I would really need separate (or multiple CPU) clients. The gist of all this is that changing numbers of servers does not seem to matter much, but that happens at a juncture where nothing else does. For what it's worth though, mod_perl tends to be consistently a little faster. >My goal is to give some kind of useful suggestion to people who need better >performance on NT than mod_perl can currently give. That probably requires a definition of performance - not easy. If the goal is responsiveness, and response times are very variable, then anything (including CGI) would be more performant, given that a stuck mod_perl freezes the entire server. Other application domains, however, will probably warrant different metrics. From the vantage point where I am standing now, fastCGI does not look bad (but I really have to test it much more than this). For people that do not like the constraints of Apache::Registry, this solution may not be ideal at all, though... Cheers, alf
