perl-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: proposed memory size test method
Date Fri, 09 Sep 2005 17:12:51 GMT
Jim Brandt wrote:
> On 8/30/05 1:05 PM, "Stas Bekman" <stas@stason.org> 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 => \@args, 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://mailchannels.com

Mime
View raw message