Re: Seeking enterprise ideas for Squid

On Wed, 2002-10-09 at 09:53, GV wrote:
> The question remains: What else can be done to improve
> networking I/O performance? In large systems, where
> one can mitigate the impact of disk I/O by throwing
> huge amounts of real memory at the problem, this seems
> to be the place to go for getting better performance
> numbers.

Squid is design bound, not machine subsystem bound. I.e. We repeat
various actions many times (for instance reply parsing and acl
processing).
 
> Disk I/O: We have not looked at this issue in great
> detail. There does seem to be an opportunity to
> improve I/O performance by using raw I/O instead of
> going through the file system. There may be other
> alternatives as well.

I don't think raw IO is a major issue in the short term. Before we can
get there we need async store lookups across the board, and distributed
(per cache dir) bloom digest creation.
 
> Multithreaded Squid: This comes up during discussion
> with enterprise customers. We are not sure it is
> necessarily the only way to go. But the economics of
> running Squid on a single box (duly partitioned)
> vis-à-vis running multiple instances on multiple
> systems can get pretty overpowering. Does the
> development community have any thoughts to share on
> the potential of a multithreaded Squid product? Or are
> there ways to run multiple instances of Squid on a
> properly partitioned SMP system, with acceptable
> levels of scaling in thruput and response time?

Squid with aufs or diskd will to a certain extent use multiple
processors today. Multi-threading or processing isn't a performance
enhancer unless you have cpu bound activity that can be sensibly
distributed across CPU's. Otherwise you tend to end up syncronising so
often, than you don't scale well. There are areas of squid that do get
cpu bound, and could sensibly be distributed. However, we need to
abstract the access to such things in to 100% callback based areas, to
allow a clean insertion point for queueing code, before this becomes a
feasible experiment to try.

In short: IMO threading is very useful, and does allow extreme
scalability when done right, but we are not currently positioned to do
it right. Doing it right IMO involves: only syncronising what needs to
be sync'd, fine grained locking of the same, and no more than 1
cpu-bound thread per CPU in the system, with an arbitrary number of IO
bound threads. (Say 16 per spindle for traditional unix IO).
  
> We are not looking for complete agreement on any of
> the ideas stated above. However, because there will be
> different views, what do people think of the notion of
> an enterprise edition of Squid, and a standard
> edition? Or is the overhead of two Squid versions
> (multiplied by the number of platforms) simply not
> worthwhile?

I loath and fear the idea. Nearly every good IO and threading model
available to 'enterprise' systems is available on *BSD/Linux/QNX/....
There is no reason to limit the use of scalability enhancing features to
'big iron' machines. There are features we should make optional (for
instance, syncronisation within a single CPU system install outside of
the IO threads is a waste of CPU.). But doing multiple versions is a
waste. What we really could use is smarter install logic. I.e. on
Solaris boxen we should default to aufs, not ufs. We should also check
various system parameters against our runtime parameters - ie the name
cache size on solaris. Doing such system tuning will give real and
immediate performance gains to most every squid install out there.

> On a related note, is it appropriate to discuss
> proprietary vendor features on this discussion list?

What do you mean?

Rob