|
Hello,
On Wed, 18 Sep 2002, Joseph Mack wrote:
> The conventional LVS wisdom is that it's not a good
> idea to build an LVS e-commerce website in which https
> is persistent for long periods.
Yes, if your site uses persistence for HTTP/HTTPS then
you better to use cookies (not LVS). If you don't care
for the HTTPS persistence (any real server can serve
connections from one client "session") then you create
normal service. In such case your care for the backend DB.
> The initial idea was that a long timeout allows
> the customer to have a cup of coffee or surf to
> other websites while thinking about their on-line
> purchase.
What happens if the client likes so much your
site that he buys products on each 10mins. Soon, the
persistent timeout should expire and the next form
can be sent to different real server (the pause between
the connections is more than 2mins). You can't predict
how rich is your client :)
> The problem with this approach is that the amount
> of memory use is expected to be large and the director
> will run out of memory. We've been telling people
> to rewrite their application so that state is maintained
> on the realservers allowing the customer to take an
> indefinite time to complete their purchase.
Also, the LVS can drop connections on OOM including
persistence templates, this hurts the persistence.
> there the calculation was done to see how long a director would
> hold up under a DoS. The answer was about 100secs for 128M memory
> and 100Mbps link to the attacker doing a SYN flood.
1 connection template for each client IP, how much?
1M clients? Then each normal connection lasts up to 2mins
if it is closed immediately after transfer.
> I'm not running one of these web
> sites and I don't know the real numbers here. Is amazon.com
> or ebay connected by 100Mbps to the outside world?
>
> What you can do with 1G of memory on the director?
More memory can be needed to buffer the attacks.
> I doubt if any website at peak load has
> 8M simultaneous customers.
Yes, may be we can't imagine such beast :) It needs
gigabits.
> However you only have 64k ports on each realserver to
> connect with customers allowing only have 64k
> customers/realserver. How much memory do you need on
> the director to handle a fully connected realserver?
No, you don't waste real server ports for connections
from client to the LVS. But using many sockets in real server
hurts.
> this is not a lot of memory. So the problem isn't
> memory but realserver ports AFAIK
Memory for sockets, sometimes the sockets can reserve
huge buffers for data.
> Let's look at another use of persistence - for squids
> (despite the arrival of the -DH scheduler, some people
> prefer persistence for squids).
>
> Here you aren't limited by shipping and handling of purchases.
> Instead you are just shipping packets to the various target
> httpd servers on the internet. You are still limited to
> 64k clients/realserver. Assume you make persistence = 256secs
Note that the port problem can be only between
two IPs. You still can reuse one port for many connections
while two connections don't have same ends (IP and port).
> This is not what we've been saying on the mailing list.
> Have I missed something?
The modern Linux kernels don't have such small limits.
If using correct model you can work with many sockets (not
sure yet for many threads). May be scheduling the work over
small number of threads loading all CPUs is a good choice.
Of course, we don't know what limits hit the different loads,
may be the memory limit, the PCI speed, the CPU limits,
not sure for the ports but playing with file descriptors
costs CPU cycles too.
> Joe
Regards
--
Julian Anastasov <ja@xxxxxx>
|
