Correct, using 127.0.0.1 should allow the
VM to make a ridiculous amount of TCP connections to itself (max ~65000
concurrent) in a very short amount of time, however the loop back address is
still ‘in’ the NIC card so those tests do not really stay self
contained in the VM, it does need to go thru the PV drivers to the virtual
network layers and back, however what it does accomplish is that you can rule
out pretty much anything external to the physical host as a test. I’m
not sure if you mentioned using PV drivers or not but that’s definitely a
How well 127.0.0.1 performs however is
kind of a moot point however as no real application would make use of this.
The real test is how many you can spin up from a physical host outside of the
virtualization platform. There’s also value in knowing how many you can
make from VM to VM.
Here is a test I have running across the
open internet… (See attachment)
This breaks down the server response time
by how long it took for DNS to resolve, how long it took to create the TCP
connection, how long it took after the connection established to start feeding
data, and how long it took to feed all the data. Also through graphing
network responsiveness it shows how much of the result is due to network
response vs server response. Running a test like this while you flood the
server might also help to gauge the weakest point and how much load you can
actually handle (which is ultimately the final question).
The server in the report above is behind a
10Mbit Fiber link, but this product is capable of testing up to 2Gbit/sec in a
virtual environment. Feel free to contact me FMI
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Carl Byström
Sent: Tuesday, May 24, 2011 5:46
To: Pasi Kärkkäinen
Subject: Re: [Xen-users] Bad TCP
Russ, I tried this using only local loopback (127.0.0.1) to minimize
any external factors. Does that make a difference to what you were suggesting?
Appreciate any help I can get on this.