|
> > (1) Load balancer bottlenecks
> >
> > (a) max open connections is limited to the number of available ports
(65535-1024 divided by TIME_WAIT). For systems with TIME_WAIT set to
recommended 4 minutes, this limits max open connections to measly 268.
> > See http://support.zeus.com/doc/zlb/sizing_guide.pdf
>
> Unless I'm mistaken, there's no "open" connection, just tracked
> connections. The clients are not "connected" to the load balancer.
>
> And BTW, your computation is only valid for a client, not a server.
> Assuming a client always uses a different port for an outgoing
> connection, it can roughly initiate 65K connections.
>
> On the server side, there's no port limit for a daemon listening on a
> single port: it uses just one ! The port used by a client is bound to
> the client machine, not the server. Several clients can have the same
> source port.
>
> If there was no file descriptor limit nor memory constraint, a server
> could handle way more than the current "port limit" (65K) simultaneous
> connections.
But doesn't a load balancer act as both server and client? It seems to me
that a load balancer would have to act as a TCP client when it forwards
packets to the actual web servers - ie open outgoing connections - and thus
won't it be subject to the port limits?
> > (2) Server bottlenecks
> > (a) Linux max open connections due to available ports or file
descriptors on the web server.
> Right for file descriptors, wrong for open connections.
For a webserver I guess there's no port limit, since there's no need to open
outbound client connections.
thanks
ed
|
