Re: Too many mempool allocations.

Right. Thats some of what the newhttp code does, It's based around the
filter concept. The interface is haphazard at the moment, but the goals
are

implement the protocol intermediary we discussed way back (renamed to
broker)

establish a interface that allows http/1.1 ranges/te/normal operation
but is orthogonal to http itself. That should allow ftp/rtsp/object
stores to interact with the broker as sources and sinks in the same
fashion as protocols for external clients and servers do.

implement fully http/1.1 compliant basic proxy, add caching in later.

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Adrian Chadd" <adrian@creative.net.au>
Cc: <squid-dev@squid-cache.org>
Sent: Saturday, May 05, 2001 6:33 PM
Subject: Re: Too many mempool allocations.

> Adrian Chadd wrote:
>
> > In either modio or commloops I played with a single temp buffer
which
> > was linked to the client state. This cut down on the mallocs a
little,
> > but quite a bit of the mallocing went to the strings on the client
> > and server (and back? :-) side.
>
> Right, and when playing with writing a client within Squid I notices
> that the http-header pack/unpack step is actually not at all needed.
We
> always have a memobj available with the headers unpacked (even on
cache
> hits I think)

The store doesn't unpack the headers on cache hits. It does at one
point, but not in the right order/location.

> Note: Some of the other "clients" are confused by this and do the
wrong
> thing by overwriting the memobj reply, for example the digest fetch
> client.

This should be clarified when we've got the broker interface specced.

Rob

>
> --
> Henrik
>
Received on Sat May 05 2001 - 04:54:46 MDT