Re: [Zope] Why do I have to reimport External Methods ?
On Sat, 20 Mar 1999, Jeff Bauer wrote:
"James A. Hillyerd" wrote:
If I do have to continue the shutdown/restart process, is there any way of tuning PCGI so that it loads up faster?
In the pcgi/Util directory, you'll find a killpcgi.py script. You could hack it to perform a restart, i.e. launch a new pcgi process after killing the old one. This would speed up your initial connect time and be much faster during debugging (multiple restarts).
But wouldn't that kill the Zope process instead of having it shut itself down? How gracefully does Zope exit when receiving a SIGTERM?
Best regards,
Jeff Bauer Rubicon, Inc.
[] James A. Hillyerd <jamesh@altavista.net> Java Developer [] HyperGlyphics: http://www.hyperglyphics.com/ [] GPG Public Key Fingerprint for 1024D/9F956CDE (Expires 2000-02-01): [] C86F B073 92DF 1E24 EF0B 0118 6061 0FEC 9F95 6CDE
On Sat, 20 Mar 1999, Jeff Bauer wrote:
"James A. Hillyerd" wrote:
If I do have to continue the shutdown/restart process, is there any way of tuning PCGI so that it loads up faster?
In the pcgi/Util directory, you'll find a killpcgi.py script. You could hack it to perform a restart, i.e. launch a new pcgi process after killing the old one. This would speed up your initial connect time and be much faster during debugging (multiple restarts).
A simple way that works for me is, when debugging, have a normal cgi version postfixed with -c and use that. This brings me to another thing: the default zope distribution doesn't include ZCGI and friends, I assume because Zope users supposedly have no interest in normal cgi. I think it should be included anyway, so that Full Zope is a superset of Only ZP/ZT. That's more intuitive, and then you don't have to download both if you want to use both :) And ZCGI.py is only a small text file, after all. And perhaps zope users are interested in ZCGI after all, or does zope make assumptions about running persistently (can't see how it could, without violating http's statelessness). And as far as tuning pcgi: you could shorten pcgi_socket():delay or the 2 second sleep() at the end of pcgiStartProc(). The first one could probably be pretty safely shortened with the miniscule cost of a chance of a few extra connect() calls, but the second one should probably stay the same, although I'm not clear on its purpose (give time for the child to sort itself out?). Here's a random question: how come the win32 pcgiConnect uses CONNDELAY (defined in pcgi.h as 1), while the unix version says int delay=1; ? See, that's the problem with open source: all sorts of grubby randoms can go rooting through your code :)
Quinn Dunkan wrote:
And as far as tuning pcgi: you could shorten pcgi_socket():delay or the 2 second sleep() at the end of pcgiStartProc(). The first one could probably be pretty safely shortened with the miniscule cost of a chance of a few extra connect() calls,
You may season to taste. The 2 second pause seemed safe enough on most tested systems, since we're flying blind. We've reserved an extra header byte to designate out-of-band data that could be much smarter about how to handle this, eventually.
but the second one should probably stay the same, although I'm not clear on its purpose (give time for the child to sort itself out?).
I don't have the code here, but it's probably trying to avoid some problem that I encountered when it was missing <wink>.
Here's a random question: how come the win32 pcgiConnect uses CONNDELAY (defined in pcgi.h as 1), while the unix version says int delay=1; ?
Probably historical flotsam. The win32 portion of pcgi is almost a completely separate product and only coexists with its Unix cousin by virtue of an overabundance of #ifdef clauses. I've mentioned this before, but it probably won't hurt to repeat. I don't think the win32 version of pcgi as the best solution for this sort of thing. It's mainly there to fill out a niche. Process launch is more expensive under Windows than Unix, so the Medusa/ZServer approach is probably more sensible in that environment, where good performance is desired.
See, that's the problem with open source: all sorts of grubby randoms can go rooting through your code :)
I don't consider that a problem. ;-) Best regards, Jeff Bauer Rubicon, Inc.
participants (3)
-
James A. Hillyerd -
Jeff Bauer -
Quinn Dunkan