Re: [squid-users] Architecture

From: Ronan Lucio <listas_at_tiper.com.br>
Date: Thu, 25 Jun 2009 17:28:02 -0300

Hi Amos,

Thank your for the valuable answer.
I'm sorry for the delayed reply, but I need to first read more about
CARP and architecture to better digest it.

Now these things seems to be getting clear in my mind.

Amos Jeffries escreveu:
> What kinkie means is that the efficiency is determined by the type of NAS.
>
> Squid performs a high-churn random-access IO when in full operation. And
> needs to do so at the highest possible speed. The absolute _best_ solution
> is to have a high speed storage device spindle dedicated to just one
> cache_dir in one Squid. None of the SAN/NAS I'm aware of can make that kind
> of find-grained assignment.
>

Actually, only the application servers and the third (lighttpd for
static... if so) would have access to the storage.
Squid servers would read and write cached file localy in a SAS HD.

> Almost...
>
> 1a) Squid load balancer using carp to select layer-2.
>
> 1b) Squid caching servers
>
> then whatever backend you like...
>

It really seems to be a better choice.
Do you have any idea about how many page hit would handle one squid servers?
Thinking about a Dual QuadCore 4Gb RAM serving only small files (less
than 300 Kb each).

>> 2) Application server as the backend servers
>>
>> 3) A third server serving static resources
>>
>
> It's up to you whether the system is large enough to require separate (2)
> and (3).
> For small enough (for some value of small) its sufficient to combine them
> and provide caching headers to push most of the static work into the (1b)
> Squid.
>

Hmmm, the doubt remains.
I'm thinking in that third server for two reasons:
- Get out these apache process (~ 30 hits) from the application servers,
once the goal is to optimize its resources.
- Get a better performance assigning it (images, css's and js's) a
different sub-domain, that would allow client browser to make 4-6
parallel requests.

Thank you,
Ronan
Received on Thu Jun 25 2009 - 20:28:08 MDT

This archive was generated by hypermail 2.2.0 : Fri Jun 26 2009 - 12:00:04 MDT