Mailing-List: contact test-dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@perl.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Thu, 08 Sep 2005 15:35:09 -0400
Subject: Re: proposed memory size test method
From: Jim Brandt <cbrandt@buffalo.edu>
To: <test-dev@perl.apache.org>
Message-ID: <BF460AAD.C8DF%cbrandt@buffalo.edu>
In-Reply-To: <431491DC.60101@stason.org>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

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.

Jim