Seeking enterprise ideas for Squid

Hello All,

Currently, Squid performance is not on par with that
of other (proprietary) cache engines. At ViSolve, we
have been looking at two specific areas for potential
performance improvement within Squid. I am sending
this email to gather your experienced views and
guidance for getting best enterprise level performance
for Squid.

The following findings and suggestions are not
entirely substantiated by objective data, but have
certainly been anecdotally supported by a couple of
large potential customers.

Network I/O: Instead of polling client connections,
Squid could employ an interrupt mechanism to determine
the next “ready” client. We implemented RT Signals
(targeted at improving performance by reducing network
I/O), and got a lot of help and support from the Open
Source developers. (The intent here is not to glorify
RT Signals vis-à-vis polling. Rather, it is an example
of the kind of ideas we are looking for in order to
bring Squid performance progressively closer to the
“desired enterprise level performance” as defined by
some of our potential clients).
 
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.

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.

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

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

Looking forward for your valuable views.

Regards,
GV
http://www.visolve.com

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
Received on Tue Oct 08 2002 - 17:53:36 MDT