|
Hello,
On Wed, 10 Jan 2001, Joseph Mack wrote:
> On Fri, 5 Jan 2001, Julian Anastasov wrote:
>
> > I'm looking in my stats for the banner servers that serve only
> > static images, LVS/DR. Wow, I have the stats in packets/sec and not in
> > bytes/sec. Can you believe, the input packets are 90% of the output
> > packets.
> .
> .
> > So, it seems all my real servers have equal number for in
> > and out packets. If I have 32 real servers for each 32 packets
> > I will send only one output packet in WIN2K/NLB mode. Oh, yes, there
> > are full-duplex links too.
> >
> > Guys, what show your stats for the incoming and outgoing
> > packets in your real servers?
>
> In my performance testing
>
> http://www.linuxvirtualserver.org/Joseph.Mack/performance/single_realserver_performance.html
>
> I found
>
> 1. that the maximum rate of packet throughput is independant of the packet
> size (this is a tcpip problem, not an lvs problem). Thus if only 150 byte
> packets are being passed instead of the mtu of 1500 bytes, then 100Mbps
> ethernet will be limited to a throughput of 10Mbps.
Yes, in your setups you test the real service and there can be
difference for TCP and UDP, in packets. But when the packets are forwarded
from the LVS box theere is no difference in the handling. LVS just
forwards IP packets. The problems, if any, can be in the TCP/IP
implementation in the real servers. Looking in my tcpdumps I don't see
any TCP problems with Linux as real server, may be you mention the known
problem in the previous kernels. My stats show in:out ~= 9:10, for
web images, served from working TCP/IP implementation. Of course, in
production the results depend on the clients, the distance, whether
TCP retransmits, etc. The final ratio is 9:10 for my setup.
>
> 2. I expect all packets need to be ACK'ed.
>
> Thus the expected assymetry with LVS-DR of ftp downloads (where large
> packets, ie mtu size, are being sent from the real-server to the client,
> while the client is only sending ACK's), does not get us anything. The
> packets are 1:1 inbound and outbound. In the outbound direction, a 100Mbps
> link will be carrying 50% mtu sized packets (giving 50Mbs), while the
> inbound throughput, having the same number of packets, will only have a
> small amount of payload (say 1Mbps). The link will then be saturated at
> 51Mbps.
In theory, not all TCP packets are ACKed (delayed ACKs). But
sometimes packets are dropped, retransmitted, etc. There is a slow
start that can lead to the observed ratio.
Yes, the picture in bytes looks very different. And the
performance tests show that we can safely ignore the byte stats as
inaccurate.
I don't have FTP stats. I don't think the FTP stats will be same
as the web stats but FTP stats from production would be very interesting.
This in-out asymmetry does not depend on the used LVS forwarding
method. It is a mess from transport and application level actions. If
for web we assume 1:4 (or another) in-out ratio (may be even in bytes),
in production we see that it is 1:1 in packets. But we can say that this
is for TCP data < 16KB (my files are near this size). Of course, for
long transfers we will see the delayed ACKs in action, may be in the
long FTP downloads.
> Joe
>
> --
> Joseph Mack mack@xxxxxxxxxxx
Regards
--
Julian Anastasov <ja@xxxxxx>
|
