|
Hi Julian:
I 100%, completely, fully understand the difference between LVS masquerading
and Linux masquerading. My point is that LVS does not live in a vacuum.
Other system parameters affect it - if one is not aware of these side
effects than an LVS box (not just the few snippets of code that implement
LVS but the LVS system as a *whole*) can easily be a bottleneck. That is not
an opinion - that is a fact. I thought it would be helpful to share my
experience with others who may run into the same problem under heavy load
rather than letting them figure it out for themselves. I sort've thought
that was the point in having a mailing list. Perhaps it would be better in
the future if I just keep my experience to myself and let others blindly
rediscover what I spent so many hours working out.
-d
-----Original Message-----
From: Julian Anastasov
To: Dan
Cc: '''Drew Streib ' ' '; '''Cono D'Elia ' ' ';
'''lvs-users@xxxxxxxxxxxxxxxxxxxxxx ' ' '
Sent: 5/13/00 8:03 AM
Subject: RE: lvs bottlekneck
Hello,
On Sat, 13 May 2000, Dan wrote:
> Well, rather than dragging this down into a pedantic discussion of
details,
> let me restate my point:
>
> If you are running a proxy server with heavy load, or large number of
users,
> just increasing the LVS tables may not be enough. You may have to
increase
> the size of actual kernel masquerading tables or suffer severe
performance
> hits. That was the reason I posted this to start with because, as the
> subject line states, it was a discussion of the lvs becoming a
bottleneck.
> There was a statement that the lvs couldn't be the bottleneck, to
which I
> disagreed, because in my particular situation, the LVS *was* the
bottleneck.
> That only changed after modifying kernel source code & recompiling.
But you change the masquerading, not the LVS parameters.
I think, you don't see the difference. LVS balances the proxy
traffic and the masquerading handles the ftp/http traffic.
Of course, the masquerading is not tuned for high-end servers.
Anyway, I agree. Anyone can have opinion.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
