[dns-operations] Stateless-TCP performance testing tool [Was: DNS Performance Test Over TCP]

[Francis Dupont]

 In your previous mail you wrote:

>  As you stated correctly "You're [...] testing the two TCP stacks", and
>  I think this might be a problem.
>  If I'm correct, Francis' tool (perftcpdns) was run from a single
>  computer hammering the tested DNS server.

=> you can use the tool on two client computers too (I tried and it was not
faster, i.e., the total rate was not cleary higher than with one client).

>  Specific kernel customizations were required on both computers to
>  achieve the rate of 30 kq/s.

=> The reuse of closed connection ports is not very specific or uncommon,
in fact IMHO the reason it is not enabled by default is this kernel
tuning ("customization" suggests to recompile) is not very compliant...

>  I have several concerns about this methodology:
>  
>    * The client might be the bottleneck

=> the client kernel is clearly a bottleneck but you can avoid it when
the tool is a standard network application.

>    * The same client, with always the same source IP address is
>      hammering the server.

=> the only drawback with this constraint (from the "standard network
application" point) is that it is possible (i.e., too easy) to run out
of ports. For instance you must close TCP connections as soon as possible
on the client side.

>      In real-world operations, this only happens
>      when the system is under-attack and this attack is easily thwarted
>      by setting up a maximum number of concurrent TCP connections per
>      source IP.

=> fortunately there is no such thing, mainly because to enforce such
a limit is too expensive (cf. the messages about DNS servers behind
a firewall).

>  A better performance testing methodology

=> before discuting about a methodology we have to discuss about
what we want to test. Here it is standard TCP (i.e., no T/TCP or
other "improved" TCP) used to replace UDP (i.e., only one query
and close after the response or on timeout). So it is not a problem
that in fact it tests the TCP stack and not the DNS service at all...

Thanks

Francis.Dupont at fdupont.fr