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?
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 suppose we can have both methods in A-T. They could live in something
like Apache::TestMemoryLeak?
BTW, in idiomatic perl the following:
for (my $i=1; $i<=$request_count; $i++){
is better written as:
for my $i (1..$request_count) {...}
:)
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.
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.
--
__________________________________________________________________
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
