Dustin Mitchell
dustin at ywlcs.org
Wed May 29 19:53:12 EST 2002
On Thu, May 30, 2002 at 10:38:51AM +1000, Martin Pool wrote: > > > Even with gc, if there are any dangling references into one of the old > > modules (an atexit function? somewhere the Python standard libraries cache a > > reference?) then you're going to have a bloated httpd. > > Using atexit functions within mod_python is pretty pointless, but your > general point about references held by system modules is correct. > > If my code bloated that easily because of reloading modules then I > would be somewhat worried that something would cause it to happen > during production, and I'd feel I ought to investigate what was going > wrong. > > You can always turn down MaxRequestsPerChild, or indeed turn off > autoreload. Ah! I had forgotten MaxRequestsPerChild, which lets Apache take care of counting reloads, so a Python reloader need not worry about it. > I guess in general I believe that in development mode (as opposed to > release), correctness and developer productivity is more important > than performance. I don't disagree. You'll note that I'm arguing for features on the basis of developer convenience at minimal (but not zer) performance cost, which translates into developer productivity. > In deployment mode, there shouldn't be any bloat because the .py files > won't change. The cost is just stat'ing them each time, which is a > slight cost but not terrible. And the cost will be zero, if AutoReload is turned off :-) > As far as I can see, the only non-bogus use of persistence is > opportunistic caching. Modules have to cope with losing their > persistent state because (a) requests are unpredictably spread across > Apache instances; (b) Apache can kill and restart children; (c) > relying on it is overly fragile; and (d) without a working reload > mechanism, the programmer will be completely restarting Apache at > intervals anyhow. True, but there are valid reasons to want to test and develop such opportunistic caching mechanisms (since anything opportunistic is by at least a little bit nondeterministic, it probably needs the most testing). There are also performance implications, as I detailed in my other reply in this thread (<20020530004544.GF2519 at eleanor.internal.ywlcs.org>). As I said a few paragraphs earlier, developer convenience with minimal impact on performance. BTW: I assume you're not implying that opportunistic caching is overly fragile! It's a great technique! Relying on not being reloaded, however, is obviously stupid, since the Apache API *will* reload you :-) I don't actually care too much about this whole thing; just putting in my $0.02. If y'all are really opposed to it, don't put it in. I'll still love you, and you can keep the pennies. :-) Dustin -- Dustin Mitchell dustin at ywlcs.org http://people.cs.uchicago.edu/~dustin/
|