Re: building async-calls

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.

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....

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

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.

Regards,
   Christos

Adrian Chadd wrote:
> On Mon, Dec 17, 2007, Tsantilas Christos wrote:
>> Hi Adrian,
>> As I am seeing squid3 spends time in EventScheduler::schedule method.
>> This method did not affected by the new AsyncCall code. Also this method
>> is similar with squid 2.6 eventAdd function.
>
> Yes, but you're using an event system which wasn't designed for massive
> amounts of immediate events for, well, massive amounts of immediate events.
>
>> The only I can say is that possibly we are scheduling a huge number of
>> events in squid3.
>
>> If the time spend while creating the ev_entry class possibly we need a
>> (better?) memory allocator.
>
> .. or don't allocate so many of them.
>
>> Also there is a for loop in this method. Most event scheduled with when=0
>> so they attached at the end (or near the end) of the events list (but we
>> are running all the list). If we have a big number of events (1000 or
>> more) it is possible to spend a lot of time here.
>> But if this is the problem it is easy for someone to fix it, we must not
>> worry about it at this time....
>
> As the guy who found the bung garbage collection in Squid-3 at least 12 months
> ago, causing CPU to chewed through at a crazy rate, I think its worth keeping
> this in mind and thinking (and benchmarking!) a way around this.
>
> It shouldn't be that difficult. But what I don't want to see is someone
> building an interface which will perform badly, do a whole lot of work
> within it, commit sweeping changes to how things are done,
> and then wonder why stuff performs badly.
>
> I'm sure its something like:
>
> for (E = &tasks; *E; E = &(*E)->next) {
> if ((*E)->when > event->when)
> break;
> }
>
> And > should be >=, so it doesn't walk a whole lot of 0.00 (now) events
> waiting for them to complete.
>
> Of course, what you guys -should- be doing really is not using this
> loop, but instead building a simple dlink list (or whatever data type
> in C++ is comparable) and just appending events to the end. O(1) and
> all that. This event loop is for scheduling events at some point
> in the future and I think overloading it is a bit silly.
>
>
>
>
> Adrian
>
>
Received on Mon Dec 17 2007 - 10:32:19 MST