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.
