Re: Squid-2.6 merge fest, and devel.squid-cache.org policy (cleanup time)

Adrian Chadd wrote:
> On Wed, Apr 03, 2002, Joe Cooper wrote:
>
>
>>I couldn't crash it with a polymix-4. Both commloops and
>>chunked_mempools seems to have a harder time during fills than the older
>>Squids, but otherwise performance is very much equivelent.
>
>
> harder time during fills?

Yep...This isn't a conclusive statement of fact, but both of the 2.6
branches I benchmarked had a slow but steady climb in latency during the
fill--though they recovered completely for the top phases on the runs
and performed nearly precisely equally to 2.4 Squids. This can
partially be explained by disk fragmentation (as I filled the disk with
a couple of full length scratch runs and then didn't empty the disks
between each run--this knocks 6-8 hours off of the benchmark runtime,
but does leave the question of whether fragmentation is impacting
performance). However, the run of 2.5 after the 2.6 did not exhibit
quite as much latency degradation--even though if fragmentation were to
blame it would be worse for the 2.5 run than the 2.6 runs since it came
last.

Anyway, it doesn't seem to be a major concern, as the standard parts of
the run are almost identical, and the fill phase really isn't /that/
much different (close enough that I will concede that it could all be a
fluke--maybe I looked at the box funny while the fill was underway). In
other words don't lose any sleep over it...If commloops makes
integration of newer event models easier, then the mild negative is
certainly outweighed by the benefit of being able to go to /dev/poll and
kqueues to replace select or poll.

>>>This may be tricky to do without my next couple of changes to
>>>-HEAD to support this. Actually, when I manage to split out the
>>>http headers from the body, this suddenly becomes _much_ nicer
>>>to do.
>>
>>Doesn't this also make te (among other inline content trickery) much easier?
>
>
> Oh baby, oh baby, yes.

Good. Do that! ;-)

>>I'd like to see ranges back as soon as possible--in accelerators this
>>can have a huge impact. (Flashget and such can destroy hit ratio
>>without it.)
>
>
> I agree. Ranges _need_ to be supported. But, if any headway was
> to be made reworking the APIs to be flexible in the long run,
> it needed to come out. I'll reimplement support for them when the
> rest of the codebase has been tidied up.

Good again. I won't argue with brokenness in DEVEL code at all...I just
want to make sure that STABLE Squid's only improve in this area, as it
can be a problem for content distribution systems (i.e. a server in the
US being accelerated by a Squid in China).

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support