Re: async-calls squid3/src comm.cc,1.81.4.16,1.81.4.17

From: Adrian Chadd <adrian@dont-contact.us>
Date: Wed, 9 Jan 2008 17:34:38 +0900

On Wed, Jan 09, 2008, Amos Jeffries wrote:

> You seem to have slightly missed my point.
> That this code is currently depending on that implicit guarantee when it
> should not be. This change is the perfect time to drop that implicit
> dependency and make it clean (bug free!). Having one precursor call
> schedule its successor is the cleanest and fastest way to do that.
> Run-time speed optimizations can wait, but this is a stability issue.

... aaand we'll see you in 2015.

> Squid is fast heading towards a state where the async queue might easily
> be split between processors. That means several fast finishing calls
> scheduled after a single slow-finishing might be run before the
> slow-finishing is done.

My opinion, if you see this as a direct path to SMP-ness then I think
.. well, its just not going to work in any sane timeframe.

You need to tidy up the code or you'll try threading huge amounts of
horrible code, and hm, if you do the tidyups properly, you shouldn't
have any issue hitting ~10,000 req/sec for small objects on modern
hardware.

At which point you'll probably discover the top CPU users are things like
regex processing, so you'll almost certainly be much better off building
a generic multi-thread event loop where you can spawn off threads
servicing their own event loops, and then "shuffle" code into them
as modules are made thread aware.

Of course, because so much of Squid is tightly coupled in the main code
you'll probably find threading -that- a pain in the ass, and you might
want to re-evaluate what you're doing.

SMP will be a pain in the ass to do right, or it'll be done wrong and
we'll end up with a pile of poo that not only is ugly internally, poorly
documented and resource hungry, its now running in parallel.

If you want to do SMP then either tidy up the codebase or identify
which bits are CPU intensive/potentially blocking and shift those into
seperate threads. I'd suggest the very first thing to do is think of
how to seperate out regexp processing into 1 or more threads so batches
of regexps can be tried against data.

Adrian
Received on Wed Jan 09 2008 - 01:25:33 MST

This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST