Poorly controlled experiment on Swift over SSH tunnel

[jennydaman]

Motivation

We were graciously offered 50 TB of space as a privately-accessed SLURM scratch space from the MGHPCC. We would like to use it as storage space for CUBE, which would require hacks upon hacks. This is an experiment to assess the inefficiencies of the various workarounds we might use.

Experiment

Our experiment will be uploading files to CUBE.

• independent variables: CUBE deployment
  • network location of Swift
  • whether or not an SSH tunnel is used to connect Swift and CUBE
• dependent variable: time it takes to upload 50 100MB files

Machines

hostname	location
olympus	BCH
centurion	BCH
cube.chrisproject.org	BCH DMZ
ferrous	Jennings' home
macrophage	Jennings' home

The command to upload files:

time chrs upload --username chris --password chris1234 --address https://cube.chrisproject.org/api/v1/ --path delete-me-later *.dat

We are using chrs version 0.2.3

Clean up experiment:

xhs -a chris:chris1234 cube.chrisproject.org/api/v1/uploadedfiles/search/ fname==chris/uploads/delete-me-later limit==100 accept:application/json | jq -r '.results[] | .url'  | parallel xhs -a chris:chris1234 DELETE

Results

Client	CUBE	Swift	CUBE<-->Swift Connection	Result
macrophage	ferrous	ferrous	localhost	1 min 30 sec (2 trials)
macrophage	ferrous	ferrous	SSH localhost-->localhost	1 min 47 sec (2 trials)
olympus	cube.chrisproject.org	cube.chrisproject.org	localhost	54 sec
olympus	ferrous	ferrous	localhost	4 min 6 sec
olympus	ferrous	centurion	SSH centurion-->ferrous	8 min 17 sec

Conclusion

• SSH introduces a small but measurable delay of about 15% slower.
• If Swift is on a different network than CUBE, network trip time is additive