On Tue, Feb 18, 2003 at 07:20:14PM -0500, Jim Davidson wrote:

>>> Note that if your Tcl thread is long running, you'll need to do
>>> the right thing to manage state manually as it won't benefit from
>>> the regular cleanup/update effects of
>>> Ns_TclAllocateInterp/Ns_TclDeAllocateInterp as with ordinary
>>> transactions. A call to "ns_cleanup" or perhaps "ns_ictl update"
>>> in the body of your while loop may work.  Unfortunately this stuff

> Well, consider this a feature of AOLserver 4.0 :).  These are new hooks to
> enable regular cleanup but you don't have to use them.  Basically, the
> cleanup stuff clears out temporary ns_set's, frees global vars, and can
> detect changes in the Tcl procs from the use of ns_eval.  However, if your
> code didn't bother with this stuff in 3.x it's likely you can ignore it in
> 4.0.

Hm.  Well, 4.0 definitely seems more memory hungry.  For a particular
load, on 3.3=ad13 my (atypical) app gets up to 26 MB.  For the same
load with 4.0b2, it goes to 82 MB (3.2x larger).

I have two long running detached threads, so in 4.0, I tried putting
"ns_ictl update" at the end of the loops in my two long running
detached threads.  Didn't seem to matter, the server still went up to
81 or 82 MB.  I tried "ns_cleanup" instead, same thing, no difference
in memory usage.  I'm don't understand what those two commands are
REALLY doing, but as far as I could tell they had no effect
whatsoever.

I also tried increasing the load by about 4x.  In this case, 3.3+ad13
went to 49 MB, 4.0 to 164 MB (3.3x larger).  Now, this likely isn't a
show stopper for me, for this app, but a more than 3x memory usage
increase with 4.0 seems like a pretty serious drawback.

Is there something other than ns_ictl update and ns_cleanup that I
should try?  Do people see this high memory usage with more typical
(serving lots of http requests) apps?  Or is my app seeing unusual
behavior?  Any insight into what's different in 4.0 that could make it
use more memory?

--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com

Reply via email to