|
Joseph Mack NA3T wrote:
> The director can't be sure that the inactive connections are
> expired. The director guesses based on timeouts. There could
> be 10 real active sessions if Act+InAct=10. Likely the InAct
> connections are in the process of exiting so probably are
> not using a lot of resources.
>
Why can't it? All packets flow through it (I'm in NAT mode).. In every
test I've done it has tracked the Active state of the connection
perfectly, as soon as the final FIN/ACK sequence passes through it moved
the connection to Inactive.
The resources used by an active Apache connection (in my case) dwarfs
the resources all of the Inactive connections the kernel might be
holding in TIME_WAIT state. As far as real-server resource utilization
goes, Inactive connections seem to be almost irrelevant.
> So set your limit to Act+Inact. If you find you can handle
> more, up the limit.
>
If I know I can only support 25 Active connections to a real-server then
how can I reliably pick a limit? The number of inactive connections
open at any moment could vary a lot depending on where the TIME_WAIT
expiry is and, as I said, doesn't really have a significant/noticeable
impact in my server compared to active connections.
Maybe there is still something I am missing, but I feel like matching
thresholds only on the active connection count should at least be a
settable option. I may look at what it would take for me to patch that
behavior into my local IPVS module.
Thanks for your reply.
Sean
|
