perl-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Brandt <>
Subject Re: proposed memory size test method
Date Mon, 12 Sep 2005 19:00:33 GMT

On Sep 9, 2005, at 1:12 PM, Stas Bekman wrote:

> Jim Brandt wrote:
>> On 8/30/05 1:05 PM, "Stas Bekman" <> 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:
>> 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/ 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/

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 =>  
> \@args, 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  


> -- 
> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
>     mod_perl Guide --->

Jim Brandt
Administrative Computing Services
University at Buffalo

View raw message