Re:Re:What to know detail about why Squid use single process.

From: <maer727@dont-contact.us>
Date: Wed, 24 Apr 2002 13:14:46 +0800 (CST)

Thanks, Henrik pal!

I have some questions on your reply,

1. What means "scalability issues"?

2. What means "es", a name of a OS?

3. What does the following sentence mean?

> A few threads to allow for scaling and offloading of complex tasks into a
> thread.

What puzzled me most is "scaling" here.
scaling means loading?

Can you give me a simple explanation?

Best regards,
George Ma

----- Original Message -----
From: Henrik Nordstrom
To: maer727@sohu.com ;Basile.Starynkevitch@cea.fr
Cc: squid-dev@squid-cache.org
Subject: Re:What to know detail about why Squid use single process.
Sent: Tue Apr 23 23:58:37 CST 2002

> maer727@sohu.com wrote:
>
> > Why you say mono-thread decision is very heavy constraining, can you
> > give me a more detailed description? Or, if it is boring and wasting
> > time, can you introduce me some articles about the topic?
> >
> > Another question, do you mean that if the Squid project starts today,
> > the group will choose multi-process? Do you have some articles that
> > compare muiti-thread with single-thread?
>
> If I were to write Squid today it would be a hybrid.
>
> A few threads to allow for scaling and offloading of complex tasks into a
> thread. Each thread handling many clients using non-blocking-io as is done
> today, or variants thereof utilizing the more fancy event mechanisms of
> modern OS:es (beyond POSIX). Giving the best of both worlds plus more.
>
> From the perspective of designing a good performing proxy, threads is no
> better than the single process design. Both approaches have their respective
> strength and weaknesses. The thread design may be easier to get started in,
> but quickly runs into code scalability issues, in many senses similar to how
> a singleprocess design runs into CPU scalability issues..
>
> Regards
> Henrik
Received on Tue Apr 23 2002 - 23:14:52 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:19 MST