[RFC] simulating network properties for benchmarks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl Friedrich Bolz wrote:
> Hi all!
> 
> This mail is trying to start a discussion about various approaches on
> how to test different network properties (latency, bandwidth, dns
> latency, etc). The test should be repeatable, somewhat easily doable
> (e.g. not involving a huge setup) and realistic.
> 
> During the performance-sync meeting we discussed briefly two general
> approaches for this:
> 
>  * Using a proxy/decorator for a transport that adds some sort of
>    artificial overhead to every operation, like time.sleep or similar.
>    This has the advantage of being relatively easy to implement but the
>    disadvantage of being quite unrealistic, since the operations on the
>    transport don't really map in a straightforward manner to what is
>    going on at packet level.
> 
>  * Simulating network properties on a lower level. If done right, this
>    would be quite realistic. It may be harder to implement (but Robert
>    hinted that he might have some ideas how to do it easily). The
>    only somewhat simple idea I have currently is using netem
>    (see http://linux-net.osdl.org/index.php/Netem) to slow down network
>    operations. Works only under Linux and some care has to be taken to
>    get it right.
> 
> Thoughts?
> 
> Cheers,
> 
> Carl Friedrich

I wonder if we couldn't put an intermediate socket into the mix instead.
So that when you 'connect' to HttpServer, you are actually connecting to
a socket that will then connect to the real socket, and just copy the
data across, only with delays, etc.

I looked into netem, and it does indeed work. Interestingly enough, if
you add 100ms delay to the loopback, you get a delay of 200ms.

I would be a little concerned about the impact of doing this on an
automated machine. You would have to be careful that you clean up, or
the machine could get really unpleasant to use. In my testing, though,
modifying the loopback really doesn't have an effect on remote access.
So someone *could* get in and fix the machine if it didn't reset itself
properly.

I would probably prefer a proxy socket, since that has a better chance
to be cross platform. But possibly 'netem' is easier to get started with.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEv/TwJdeBCYSNAAMRArlWAJ9ni1LO5Vb1dC0I9DAXu1YQbejQTwCbBk7x
LLAjSVGWymGf+65ijb9Yu3I=
=vfza
-----END PGP SIGNATURE-----