I ran hammer_ssh against qastaging from devpad. Using these options:
$ python ~/hammer_ssh.py --load=200 --delay-after-spawn=0 --run-time=60 --server=bazaar.qastaging.launchpad.net
That attempts to spawn up to 200 concurrent processes all trying to run "echo hello | ssh bazaar.qastaging.launchpad.net" and when ones disconnect, it spawns another one for 60 seconds. The result was:
Spawned 1791 connections in 66.106s
average time: 6.893s
1791 connections in 66.1s means we started 27 connections per second. Since the average run time was 6.9s, that means we averaged 27*6.9=187 concurrent connections.
Not all of these would have had active bzr+ssh processes at the same time. However, it does show that we can spawn thousands of connections over time, and it doesn't appear to be leaking any file handles.
I ran hammer_ssh against qastaging from devpad. Using these options: after-spawn= 0 --run-time=60 --server= bazaar. qastaging. launchpad. net
$ python ~/hammer_ssh.py --load=200 --delay-
That attempts to spawn up to 200 concurrent processes all trying to run "echo hello | ssh bazaar. qastaging. launchpad. net" and when ones disconnect, it spawns another one for 60 seconds. The result was:
Spawned 1791 connections in 66.106s
average time: 6.893s
1791 connections in 66.1s means we started 27 connections per second. Since the average run time was 6.9s, that means we averaged 27*6.9=187 concurrent connections.
Not all of these would have had active bzr+ssh processes at the same time. However, it does show that we can spawn thousands of connections over time, and it doesn't appear to be leaking any file handles.