Re: ayjwork squid3/src HttpRequestMethod...

Adrian Chadd wrote:
> On Sun, Feb 03, 2008, Amos Jeffries wrote:
>>> Please give an example or two, where the performance would noticeably
>>> suffer for standard methods.
>> There were several switch(e->method) in what I think is the request
>> processing pathways. I was thinking making that switch into a series of
>> string comparisons (on image()) would increase the processing ops where
>> the current index int checks are faster.
>> src/client_side.cc:630 - clientIsContentLengthValid(HttpRequest * r)
>> src/forward.cc:467 - checkRetriable()
>>
>> I don't think it would be a _great_ sufferance, but it would be a small
>> unnecessary backslide. Making the enum 'methods which squid has special
>> internal processes for' would be simple and easier to maintain than
>> attempting to keep a comprehensive list with unexpected 'others' also
>> accepted silently.
>> And have the benefit of a low amount of change to the code for the same
>> gain.
>
> The current codebase is too poor performing for that particular string
> comparsion to have a noticable effect on performance.
>
> Of course, if you guys actually want things to perform comparable to what
> other projects are doing in the future, this sort of "death by a thousand
> cuts" is one sure fire way to make that more difficult.

That's my line of thinking. 1000 slices wasted, 999 slices wasted, ... 0
  slices :-)

>
> Just abstract stuff out enough so the "do i use the ID or do I use a string"
> is done in one place, with another method exporting the "data" to use
> in the md5 key generation.

Thats the way it stands now. You can pick to check ::id() (fast but
limited by registered enums) or HttRequestMethod::image() ('slow' but
full-text comprehensive)

With a little wasted RAM used by extra methods explicitly named in the
enum array. 1-2KB savings? slice ;-) ...

<dream>
When your string/buf mods get in there we won't need the array at all.
Keeping String theImage as a ptr to the actual buffered request headers.
</dream>

The problem with MD5 is what the side-effect of altering the MD5 in
store will do. Would it make older caches after upgrade 'loose' all
their content as never-matching-again objects?
I don't know enough at this point to answer that one.

Amos

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.