Re: Seeking enterprise ideas for Squid

On Thu, 2002-11-14 at 15:44, GV wrote:
> Hello All,
>
> Some time back I had sent you an email seeking your feedback on some
> specific issues. A lot of you came back with your comments. Thank you
> all for taking the time, and also my apologies for taking this long to get
> back on the forum.

Thats quite alright, it's the main purpose of mailing lists - to
decouple exchange of ideas from syncronicity in space-time.

> To summarize, I had sought your feedback on the following items:
>
> The appropriateness of discussing "proprietary" Cache server products.
> ================================================
> Wrong choice of word. I really meant "commercial" systems, which play in
> the same space as Squid.

Ah. Thats fine. We can discuss anything here as long as we are not
talking about someones trade secrets.

> This was one reason we had looked at improving in-memory operations via the
> RT Signal enhancement. There is some more work to be done on that front,
> but the main point here is that the motivation for doing something like RT
> Signal work actually came from the exposure to vendor and commercial product
> discussions.
>
> To close on this, the question is really not about discussing the specifics
> of other products. Such a discussion may often be inappropriate. But it
> should be possible to discuss performance (and functionality) ideas without
> naming names. One may well have derived those ideas through exposure to
> other products. Right?

Yes. Standard black box reverse engineering is unlikely to be an issue.
I reserve the right (and I expect the other core members do too) to jump
in and halt a discussion if it does become problematic. I don't recall
that *ever* happening though, and we've discussed things like
Microsoft's NTLM over HTTP in detail here before.
 
> Regarding an Enterprise version of Squid
> ===========================
> Once again, I probably said something that detracted from the main issue.
> It really is NOT about enterprise version vs. non-enterprise version of
> Squid. This idea, not unrelated to the previous one about commercial web
> cache server products, stems from an observation and hunch that our high-end
> enterprise customers are generally not drawn to Squid. Is this a name
> recognition issue, a general enterprise aversion to put "open source"
> material in high-end production - all in all, a perception and brand
> recognition problem?

I'm currently working with a large Australian company, and they use
Squid by choice. They have an outsourced IT provider and still, squid is
their cache of choice.

> Or is this real? From our informal measurements, and from the knowledge of
> the types of concurrency and responsiveness desired by high end customers,
> the issue may be real.

I think that there are some issues in the high end of town performance
wise. However, the cost difference seems to be such that a squid cluster
will outperform an equivalently priced off-the-self
commercial&proprietary solution. So it's really performance-per-RU that
squid lacks, and there are situations where that counts (such as
co-located servers in web acceleration scenarios).

> Specific performance analysis and enhancements for Network I/O, Disk I/O
> ===================================================
> We understand completely that a lot of interface cleanup is happening as I
> write this. But without subjecting anyone (Adrian and Robert in particular)
> to any undue inquisition or pressure, we are just curious to know the impact
> of, for instance, raw I/O on Squid response time at certain levels of
> concurrent requests.

Well, we have to define scalability and performance more clearly to
create a discussion framework. The short answer, is 'not much'. But
there is a long answer too :}. OS response degradation is a much greater
issue than sheer IO performance. When poll() takes 70% CPU, something is
wrong :}.

> Resources permitting, we may just try that. The goal
> there will be nothing more than getting an initial idea, and we will
> certainly share the findings, however informal, with the group. It is just
> a matter of finding engineering resources.

If you need engineering resources, I make my living by being a floating
engineering resource. I hack squid for pleasure, and whenever I can, for
profit^H^H^H^H^H^Ha living. Contact me off list if you'd like to discuss
this in more detail.

> Thanks again for all your responses. I would still like to understand why
> enterprise customers tend not to consider Squid in their shortlists.

So would I. Perhaps we can work on making Squid a more visible brand in
the Enterprise space (as opposed to the ISP space, where it is *very*
visible).

Rob