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
