|
Hello,
On Wed, 8 Nov 2000, Thomas Proell wrote:
> Hi!
>
> I think about doing some performance testing with testLVS. I
> read the documentaion and found out, that testlvs only generates
> traffic for the redirector, who distributes it among the
> servers.
> The servers don't answer, do they?
There is a reason the real servers to answer if you want to
test the real servers' SYN flood defense.
> So, you only estimate how many connections per second can be
> established with LVS. You don't take into account that in
Right. This is a test for the director's and the network's
hardware equipment, how LVS handles the connection table and
whether the LVS defense strategies can keep the LVS running under
attack/load. Nothing more.
> real environment, LVS has to deal with the "ack"-packets from
> the client.
This is not a testlvs goal.
> I'm not sure if I understood this well, and I don't know if
> the "ack"-packets do much harm.
>
> Any ideas?
testlvs generates only TCP SYN and UDP packets. Both kind of
packets are accounted as inactive connections in LVS. The effect of
this flood is to create many connections in the LVS connection table
and to see the LVS behavior under memory and network load. In the
eyes of LVS this is a very big load.
The real servers only send SIN+ACKs for the incoming SYNs
if the replies are not blocked with the route rules mentioned in the
README. We don't even reach the listening socket. You can run real
service but don't expect the requests to be detected. The TCP stack
can't complete the TCP handshake, so the socket does not receive
requests. This is a SYN flood. But for UDP you can test the real
service (with incorrect data packets because testlvs sends packets
with same data part, not suitable for any real service, just like
the data sent from ping).
There is a good reason to allow the real servers to send their
replies through the director in LVS/NAT mode. In the real situation
this is true, i.e. these packets really come to the director. But be
sure these replies don't exit your site in this test.
All these notes are mentioned in the README file. testlvs is
not designed to test the real service. Look for other tools, there
must be different tools to test web, web proxy, ftp, etc. But you can
crate UDP service that can reply to these "pings" from testlvs and
to allow the real servers to reply. You can test with different packet
size.
> Thomas
Regards
--
Julian Anastasov <ja@xxxxxx>
|
