[ please keep it on the list ] On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote: > > Two other possibilities are using a different version of Perl (like one > > with theads and one without), or accidentally using the wrong version of > > your modules. > > I don't think so. Pretty standard Debian install, Perl 5.6.1...
And you compiled both mod_perl and FastCGI yourself? > > > PerlModule CGI; > > > > You could gain more speed by replacing that. CGI_Lite or CGI::Simple > > are faster and should still be cross-platform. > > That's preloaded for some other modules. EDO uses Apache::Registry. (Which is > another possible point of suspicion, although it's not used much... And > Apache::Registry is supposed to be faster than CGI (which the FastCGI version > uses) too...) Apache::Registry is faster than a CGI script. The CGI.pm module does something totally different, i.e. parsing params. CGI::Simple implements the same interface and is a drop-in replacement, so it might be worth a try. How does the performance compare in general? Apache::Registry is slower than writing your own handler, so it could be masking your speed gain to some degree. > > Why don't you run your own server? It's easy to do, even if everyone is > > on the same machine and using the same mod_perl build. > > I've never had a need to? Our dev server is close to our prod server in > config, to aid in testing possible issues & conflicts. I do it for the reason you mentioned, i.e. restart without disturbing anyone else. > > > As a FastCGI, all I have to do to restart it is touch the main CGI file. > > > > Does that restart the whole FastCGI daemon? Without affecting other > > people who are developing on it? > > Ummm, the script IS the daemon. mod_fastcgi knows how to talk to the FastCGIs, > and manages the loading (and killing) of them. Each FastCGI app runs as its > own persistent process, and you can either statically control the number of > processes, or give it a dynamic range to balance requests with. So it takes down the script, but that doesn't affect the rest of the developers because they aren't working on the same script? That makes sense. SpeedyCGI is similar, I believe. > So when a FastCGI is thrashing your CPU, top shows the actual CGI name, and > you can restart it by killing it, or, if enabled, by touching it, with no > effect on any apache daemons, or other FastCGIs. Showing the script name in top is a nice feature. With mod_perl you have to use something Apache::VMonitor for this. > > You can specify an exact number with apache if you want to. > > But again, that limits what else the server is doing. I could have an Apache > server with 50 daemons, used to deliver images, boring stuff, mod_perl stuff, > whatever, and still control my FastCGI's processes. Yes, this is true. In production I use a front-end proxy setup for this reason. > Personally, I'd love to see a blend: Where I can have a light-weight mod_perl > style interface in all daemons, which can interface to a possibly more > limited number of FastCGIs. Gain the power of mod_perl, with the resource > control of FastCGIs. You can do that with mod_perl 2, by setting up the number of perl interpreters you want to have available for each script. See http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support - Perrin
