|
Done some testing (netmon) on this and here's my observations :
1. A connection becomes active when LVS sees the ACK flag in the TCP header
incoming in the cluster : i.e when the socket gets established on the real
server.
2. A connection becomes inactive when LVS sees the ACK-FIN flag in the TCP
header incoming in the cluster. This does NOT corespond to the socket
closing on the real server.
Example with my Apache Web server.
Client <--> Server
A client request an object on the web server on port 80 :
SYN REQUEST ---->
SYN ACK <----
ACK -----> *** AcitveConn=1 and 1 ESTABLISHED socket
on real server.
HTTP get -----> *** The client request the object
HTTP response <----- *** The server sends the object
APACHE closes the socket : *** AcitveConn=1 and 0 ESTABLISHED socket on real
server
The CLIENT receives the object. (took 15 seconds in my test)
ACK-FIN -----> *** AcitveConn=0 and 0 ESTABLISHED socket on
real server
Conclusion : ActiveConn is the active number of CLIENT connections..... not
on the server in the case of short transmissions like objects on a web page.
Its hard to calculate a server's capacity based on this because slower
clients makes ActiveConn greater than whats the server is really processing.
You wont be able to reproduce that effect on a LAN because the client
receives the segment too fast.
I reproduce the effect connecting at 9600 bps and getting a 100k gif from
Apache while monitoring established sockets on port 80 on the real server
and ipvsadm on the cluster.
Hope this clarify a bit ActiveConn and InactiveConn....
JNA
> active: all connections in ESTABLISHED state
> inactive: all connections not in ESTABLISHED state
>
>UDP
> active: 0 (none) (LVS <= 0.9.7)
> inactive: all (LVS <= 0.9.7)
>
> active + inactive = all
>
> Look in this table for the used timeouts for each
>protocol/state:
>
>/usr/src/linux/net/ipv4/ip_masq.c, masq_timeout_table
>
> For VS/TUNNEL and VS/DR the TCP states are changed checking only
>the TCP flags from the incoming packets. For these methods UDP entries can
>expire (5 minutes?) if only the real servers sends packets and there are
>no packets from the client.
>
> For info about the TCP states:
>
>- /usr/src/linux/net/ipv4/tcp.c
>
>- rfc793.txt
>
>>
>> Please excuse any excessive ignorance on my part, my personal
>> area of greater understanding is file systems and networking code
>> can be somewhat odd at times.
>>
>
>
>Regards
>
>--
>Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
>
>
>----------------------------------------------------------------------
>LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
>For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
>
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
