On Sep 9, 2005, at 1:12 PM, Stas Bekman wrote:
Jim Brandt wrote:
On 8/30/05 1:05 PM, "Stas Bekman" <[EMAIL PROTECTED]> wrote:
Jim Brandt wrote:
The reason I recently ended up diving down the rabbit hole of the
same_interp_tie method was actually that I was working on writing a
helper method to watch memory size on a mod_perl process. My
methodology was simply a brute force series of requests with a
memory
check before and after.
Also take a look at:
http://search.cpan.org/src/GOZER/mod_perl-2.0.1/t/lib/TestCommon/
MemoryLeak.pm
Thanks for the pointer. I think my proposed test method attempts
to do the
same thing as this module, but in quite a different way. To get
results from
MemoryLeak, it appears you need to add a function call to the top
and bottom
of your handler. It will then watch your process and dump some nice
diagnostics to the error log.
For t_mem, I was trying to create a method that would also watch
memory, but
externally with no code changes. So you can write a standard
external test
script, not modify your code, and find out if something is leaking
on you. I
added the tolerance in an attempt to get pass/fail behavior like a
normal
test, but with some allowance for small variability with memory
allocation.
Also, I believe t_mem will work on handlers and Apache::Registry
scripts, so
people converting to mod_perl could use it to watch their
converted scripts
if they are questionable with memory usage.
The approach above (TestCommon/MemoryLeak.pm) works for handles and
registry scripts all the same. The benefit is that you could
always bracket certain code chunks until you narrow the problem
down. With your approach you can't do that.
Am I correct so say that the benefit of your approach is in not
needing to change the source code? I guess it might be benefitial
if you code this as a test and the test fails if suddenly you get a
memory leak?
Yes, that's it. It can act as a regression test. I think it might
also be useful for people converting CGI scripts who want to just run
them under Registry and see if there are any leaks before changing
code. If it does leak, they would probably want to use the MemoryLeak
to try to narrow down the problem.
You also must ensure that you run at least 3 iterations. Since from
what I've seen it takes about 2-3 executions to get the memory
allocations stabilized. (see the explanation at the top of t/lib/
TestCommon/MemoryLeak.pm)
I think the initial default I set is 10 for that very reason.
I suppose we can have both methods in A-T. They could live in
something like Apache::TestMemoryLeak?
Sounds good.
BTW, in idiomatic perl the following:
for (my $i=1; $i<=$request_count; $i++){
is better written as:
for my $i (1..$request_count) {...}
:)
Thanks. That range operator always brings back my Ada days... :)
Also I'd keep t_mem to just return 1 or 0, so it's a test-specific
function, and have another function e.g. remote_leak to return
multiple args. Then you can use that remote_leak inside t_mem.
Sounds good.
Also to be complete you need to support more complicated requests,
i.e. not only url, but all other arguments GET accepts (like
content, headers, etc), so I'd just get the request data as url =>
[EMAIL PROTECTED], which can be many different things, which you just forward on.
OK. I may need some help here, but I'll give it a shot.
For the next step, should I take a shot at a version of
Apache::TestMemoryLeak?
Thanks,
Jim
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://mailchannels.com
==========================================
Jim Brandt
Administrative Computing Services
University at Buffalo
