Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
Greetings.
[following Stas' suggestion I have subscribed to the list and
posted the patch there, so I am crossposting]
Do you know if FastCGI is multi-threaded or multi-process on
Windows?
Multi process. Each process speaks tomod_fastcgi over a
named pipe. As you mention, this (being multithreaded) avoids the problem
to which mod_perl succumbs.
[...]
Also, which FastCGI implementation do you recommend for
Windows?
I am in the process of testing mod_fastcgi, and that being
the only one I have seen so far, I should probably reccomend it...
;) It appears to be the only apache implementation by the
way. Also www.fastcgi.com
says that implementations for IIS and Iplanet were withdrawn by the firm that
was producing them.
Setting up is a bit of a pain (though recompiling perl with SFIO
is no longer required) Recompilationsmaybe required forapache,
mod_fastcgi,FCGI.pm. Also the Apache configuration can be a little
delicate.
After setup is taken care of, however, all it took to convert
the application was changing:
use CGI;
my $q=new CGI;
to
use FCGI;
use CGI::Fast;
my $q;
while($q=new CGI::Fast) {
}
So it wasn't bad, though I have to say that the app already
clears mod_perl and straight CGI, so it is exceptionally clean (by my
standards, at least).
I did run some tests - which basically check activation times, I
am working on getting more significant number on concurrency etc. Some patterns
do already emerge though:
Testing from a Linux box with:
ab -c30 -n 60 (30 concurrrent sessions, two requests each)
I get:
mod_perl (already compiled):
Concurrency Level: 30Time
taken for tests: 5.463 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292080 bytesHTML
transferred: 280620 bytesRequests per
second: 10.98Transfer
rate: 53.47 kb/s
received
Fast CGI (throttled at 4 concurrent servers already
running):
Concurrency Level: 30Time
taken for tests: 8.018 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292440 bytesHTML
transferred: 280980 bytesRequests per
second: 7.48Transfer
rate: 36.47 kb/s
received
Straight CGI gave me a server timed out with the same values. So
I lowered it to:
ab -c 10 -n 60
Concurrency Level: 10Time
taken for tests: 139.580 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292140 bytesHTML
transferred: 280680 bytesRequests per
second: 0.43Transfer
rate: 2.09 kb/s
received
So mod_perl has a slight speed edge over fastcgi (whichis
overthrottleda littlewith four servers). CGI is glacial as exepcted
- well, a little more actually, probablyaccounting for the catastrophic
event entailed bystarting a process on NT.
I plan to run some tests also on IIS with CGI and PerlEx and if
they're interesting I'll post them.
Cheers,
alf
Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
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? My goal is to give some kind of useful suggestion to people who need better performance on NT than mod_perl can currently give. - Perrin
Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
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
