httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Tuttle <>
Subject Re: Dangerous Flood memory model compromises larger runs
Date Mon, 17 Nov 2003 16:48:03 GMT
Flood developers, APR gurus, Cliff Wooley, Sander Striker, etc.:

Looks like I'm in the process of implementing the needed fix of
implementing multiple pool levels in Flood. The decision point is going to
be between allocating a new pool from the source pool every repeated
instance (i.e. each time a url-testing is attempted by a virtual user)
which is then destroyed before the next url is encountered, or creating
the subpool for requests/responses once from its parent and clearing the
pool after each url finishes. I want to know (1) if any memory is actually
released when the pool is cleared and (2) what you see as performance hits
for each method. I notice that Flood, on a "session" level (virtual user
or "farmer" executing one round of a list of urls in a profile), performs
the second option, clearing the subpool after each session. Also, if
memory is not actually released in that event, is the cleared subpool at
least going to properly reuse the memory it has already allocated? Once
the farmer_pool has been cleared, I assume that at that time any subpools
it had would need to be recreated (by an apr_pool_create()).

-Norman Tuttle Developer, OpenDemand Systems

PS: After a call to apr_socket_connect(), is the allocated quantity
pointed-to by its 2nd (apr_sockaddr_t *) argument required to stay around
for the duration of the life of the socket, or is its value used
immediately and it can be deallocated? I will check myself but perhaps
someone knows offhand.

On Thu, 13 Nov 2003, Sander Striker wrote:

> On Thu, 2003-11-13 at 16:26, Cliff Woolley wrote:
> > On Thu, 13 Nov 2003, Norman Tuttle wrote:
> > 
> > > How do the pools define "if possible" in your wording below (i.e., how
> > > would the pool know when to reuse memory)?
> > 
> > It's kind of complicated, so I don't know how well I can explain it off
> > the top of my head (Sander, feel free to jump in here :), but it keeps
> > freelist buckets of varying power-of-two sizes, and if it finds one of the
> > appropriate size, it will use it.
> The allocator keeps freelists of multiples of 4k blocks actually ;)
> > But there are two levels of things going on, too, because the allocator
> > hands out blocks of a certain size, which the pools then divide up into
> > smaller blocks...
> Pools get blocks from the allocator.  Pools then hand out the requested
> memory to the caller.  They hold on to the 'surplus' for the next
> allocation.
> On a pool clear, all used blocks return to the allocator (except for
> the block containing the pool itself (8k)).
> > Oy.
> > 
> > Sander?  Help me out.  :)
> You know what, this question comes up reasonably frequently.  Enough for
> me to start writing a document on this.
> I'll post a URL later on.
> Sander

View raw message