Re: building async-calls

On Mon, Dec 17, 2007, Tsantilas Christos wrote:
> Hi Adrian,
>
> If you just worry about performance of AsyncCalls/JobCalls design lets
> waiting to have a progress in AsyncCalls development and see how performs.

Hey I'm glad to, as long as people test resource use regressions as they're
developing.

I do what I can with polygraph here just to make sure that I haven't boned
anything locally during development - and occasionally i do put a > where >=
is needed or similar and this blows things up! - and I'm generally quite
surprised that I pick up performance issues in squid-3 every time I sit
down and look at it. :)

> About the event subsystem in squid, it is less than 500 lines of C/C++
> code and looking in it I have in my mind 2-3 easy to implement hacks to
> improve significant its performance, if it is really problem. Because it
> is a small part of squid can easily be rewritten at any time....

Again, I don't think its a great idea to overload that events system for
general callback events. Robert had the right idea - create a seperate
event dispatcher, register it, and use that for immediate callbacks.

> And there are other parts of squid3 which also can improved, for example
> HTTP parser.

I think you'll find the HTTP parser isn't where most of the inefficencies
are. :) Profiling locally shows, in roughly this order:

* regex handling (refresh_patterns, ACL lookups)
* memset (which isn't a problem in squid-2.HEAD as much)
* memcpy (which is becoming less of a problem in Squid-2.HEAD + store_copy)
* vsnprintf and friends (need to sort -that- one out sometime)
* the mempools and system malloc
* httpHeaderNameById (need to look into this one!)

In -3 you'll probably see headersEnd() high up on the list, and maybe the headers
are being parsed a couple times too many.

Fixing the allocator overhead doesn't mean "we need a faster allocator!" just yet,
it means "maybe we could use the allocator less." The biggest allocator user?
HttpHeaderEntry's and String buffers.

Fixing memset() has been done by only zeroing buffers that need to be.
Again, this becomes less of a point when you're allocating less (as the memset()s
are basically only done during allocation.)

vsnprintf() is annoying - it seems to be used internally by a number of functions
(eg inet_ntoa()) as well as some of the request/reply packing functions. I'll
need to look into that some more.

memcpy(), in rough order:

* storeClientCopy()
* storeAppend()
* header packing
* string copying into http headers during parsing

1) is gone in squid-2.HEAD store_copy and it seems to be fine. I'm working on 4).
2) will take a little more effort as the http.c[c] code is slighly convoluted in
   its buffer use, but I expect to sort through that later on. 3), well, it depends
   on how more efficient writev() is. :)

> All these thinks should not worry us because they can fixed without the
> need of huge changes in squid3 code, and probably a number of them will
> fixed before 3.1 release.
>
> My opinion is that there are other thinks for which someone should worry
> about. For example squid (2 or 3) can not use efficiently a multi
> core/multi processor system.

If you have a slow, badly organised codebase (and I'm talking about Squid-*
here, not just -2 or -3 in particular) then SMP is just hiding the problem.
Ideally I'd like to see Squid on a single CPU, with non-disk workloads,
satisfy almost anyone's requirements in the medium term. Other web servers,
albeit without doing anywhere near as much as Squid does, can pull off
1gbps/10k req/sec on a modern single core; Squid shouldn't be any different.
SMP is important, but in this instance hardware -has- moved on and you'll
find SMP will be more important in handling things like inline content
processing, ACL matching (regular expression lookups) much more than the
raw shovelling-of-HTTP-bits. That stuff is (moderately) easy. :)

Adrian
Received on Mon Dec 17 2007 - 16:33:12 MST