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
