Oliver Nassar

I can be reached at onassar@gmail.com.

For my open source work, check out github.com/onassar


High Latency during rsync over SSH

View more posts

(see below for update)

Almost 2 years ago, I posted the following on Stackoverflow:
rsync command is slow when I'm not connected to the internet

Since then, I'd simply dealt with the issue I described. To address it again, it's as follows:

In my development flow, which I describe here, I have a Parallels virtual machine set up. It has an Ubuntu server OS installed on it that mirrors the one I have installed on my AWS EC2 instance.

It has the same packages installed, in the same way. The build scripts for my VM and my EC2 instance are pretty similar. The goal of this being to minimize technical differences between my development and production environments.

So while I'm in Coda, every time I make a change to some code, I hit a keyboard-shortcut which runs a Code Plugin that I created. This plugin runs an rsync command which pushes the contents of one directory on my OSX file system to the /var/www/ directory on the VMs. Here's the command:

rsync --delete --archive --quiet --compress --exclude '.svn' --exclude \
'.git' --exclude '.DS_Store' --exclude '.' --exclude '..' --exclude \
'.localized' --exclude 'thumbs.db' --exclude 'apc.php' --exclude '*/tmp/*' \
--exclude '*/application/webroot/uploads/*' --exclude '*/wp-content/*' \
/Users/onassar/Sites/ onassar@10.211.55.5:/var/www/;

Looks normal enough.
Execute that command with the --verbose --stats --progress flags, and you can see everything come through. The time it takes, which files were synced over, etc.

But the purpose of this post? When I'm traveling and don't have an internet connection, I still want to develop. When I try executing that plugin, with it's rsync command, the command takes ages. It's slow, and goes from an average range of 100ms - 400ms to 5,000ms - 10,000ms.

For a while, I assumed it was the rsync command that was the issue, but then today, I was reminded that simply sshing into the virtual machine causes the same slowness and latency. So I googled:

ssh slow when no internet connection parallels

And stumbled onto this:
SSH login slow (DNS works okay)

Someone is having a similar issue, and the suggestion goes something like this:
When you ssh into a machine, a reverse-DNS lookup is performed against the IP address that you are connecting from. I haven't looked into the reasoning for this, but I'm sure it makes sense. This would naturally not work since I don't have a connection to the internet (SSH seems to presume that there is an internet connection when an SSH request is received).

Their suggestion as a workaround? Create an /etc/hosts record (on the VM) that points the IP address that they're trying to do the reverse-DNS lookup against to the local machine; thereby bypassing the internet-lookup, which would naturally timeout.

In my case, this amounts to my OSX (which has an address of 10.211.55.2) IP being routed to the localhost with a rule that looks like so:

10.211.55.2    localhost

Boom. Speedy as can be.

Possible Issues

While I haven't thought too far down the line of what may go wrong if I route all traffic to my OSX connection back to the VMs, I don't think it'd be anything too problematic. After all, this web server is reliant on incoming connections.

Possible Workarounds

My first thought was that I could change my VMs configuration to prevent reverse-DNS lookups upon an initiated connection.

I may look into this when I have a bit more time and post the results here. I think it's a nicer solution than the workaround I've stumbled upon here.

Better Solution (Updated Saturday, 9 June, 2012)

Thanks to the post SSH Reverse DNS Lookup Disable and Ubuntu Linux: Start / Stop / Restart, I've discovered a better solution.

I've removed the /etc/hosts record, and edited the ssh config file by adding the following flag at the end of the file:

UseDNS no

To then restart the ssh engine, I ran the following:

sudo service ssh restart

This removes the reverse-DNS lookup upon an initiated connection.
Boom :)