Last time I looked at lighty, it buffered the entire message when used
in proxy mode; this isn't really workable.
I'd use Squid on the FE in CARP mode; CARP is a way of using
consistent hashing to spread the load out to multiple servers in a
predictable way (like a DHT).
If you need even more capacity, you could run multiple instances of
squid on the FE listening to the same socket; see
http://www1.id.squid-cache.org/mail-archive/squid-users/200810/0136.html
Cheers,
On 24/06/2009, at 9:18 AM, Ronan Lucio wrote:
Hi Kinkie,
On Tue, 23 Jun 2009 21:51:17 +0200, Kinkie wrote
Hi,
I can't see the advantage of using lighthttpd instead of squid+carp
as the frontend,
The idea of putting a lighttpd server as a the frontend is for load
balance.
What exactly do you mean with squid+carp? several squid servers
working as one?
Can I have it working in an external DataCenter?
If so it seems to be a better solution, even because it's a fault
tolerance
solution.
and if using lighthttpd i can't see the advantage of
not serving static content directly out of the balancer.
Actually, I'm just afraid of overload the server.
Initially I don't know exactly how much resources would it consume
from each
server.
If a server like that fits executing two roles, I'm sure it would be
better.
Also watch out as nfs has locking and scaling issues of its own
(assuming thet nfs is what you mean by "single filesystem"), and it
also introduces a very nasty point-of-failure.
Yes, it's a NAS.
Kinkie, the architecture shouldn't be that suggested from me.
It's just how I could figure out. Of course I want to make it better.
Do you have a suggestion for that?
For all I have understood your suggestion is:
1) Some squid servers + carp
2) Application server as the backend servers
3) A third server serving static resources
I just didn't figure out your suggestion for storage.
Thank you,
Ronan
--
Mark Nottingham mnot@xxxxxxxxxxxxx
