Jan 23 2007
Getting burned by latency
I decided to upgrade WordPress from 2.0.4 to 2.1 today mainly for the spell check, the autosave feature, and the improved AJAX interface. Before doing so, I had to backup my blog in case I screwed it up. Backing up my blog consisted of two parts:
1. Backing up the SQL database file that contains all the posts, comments, and visitor statistics. This file is about 12MB because FireStats logged all 6230 hits since September. (Most of them are search engine bots.) Next to each hit number, the database file has the IP address, the timestamp for the hit, what page was viewed, the referrer, the operating system of the user, and the browser of the user. That’s a lot of information.
2. Backing up all of the WordPress blog settings, WordPress themes, WordPress theme settings, and pictures I’ve uploaded. All of this was about 9MB.
Guess which one was a bigger pain to download. Pain to download? How is downloading 10MB or so a pain over a broadband connection?
The 12MB SQL database file finished downloading in just a few seconds. No big deal. But the 9MB of WordPress settings and pictures? It was a big fat pain. Believe it or not, it took 40 minutes.
Why would 9MB worth of WordPress settings and pictures take 40 minutes to download? I got burned by latency. Latency and throughput are two different things:
Suppose you have data going from point A to point B…
Latency is the time it takes a single bit of data to travel from point A to point B.
Throughput is the rate that data arrives at point B once it starts arriving.
Since the 12MB SQL file was just one file, my download time was the initial latency at the beginning of the download (about 100ms) plus download speed/file size. In contrast to the 12MB SQL file, my 9MB of WordPress settings and pictures mainly consisted of very small files. I transferred this data to my computer through FTP, and for each file, my FTP client would ask the server to send a file, the server and my FTP client would negotiate the transfer, the transfer would take place, my FTP client would acknowledge to the server that it received the file, and then my FTP client would ask for another file. In other words, FTP can be very “chatty.” When the FTP client and the server repeatedly exchange small bits of information back and forth, the download or upload speed doesn’t really matter, it’s the latency that kills you.
How much did the latency kill me? Most of the WordPress files are 100 byte files (no, not kilobyte, I really mean byte) and there are hundreds of them. Even though that stuff was just 9MB, it was a pain to transfer. Asking for a file probably took 100ms, negotiating the transfer probably took another 200ms, transfering the file probably took next to no time, and the FTP client telling the server that it got the file probably took another 100ms. That’s at least 400ms just to transfer a 100 byte file. That’s freakin’ slow. If I had shell access to my hosting account, I would’ve compressed everything into one file and downloaded that one file so that I can pay the latency penalty only once.
This latency problem is fairly basic. Someone had to figure out a fix to this. Fortunately, someone has. Riverbed has put together a network appliance that will optimize WAN traffic so that applications aren’t as chatty across a high latency connection. Compared to their competitors in the WAN optimization market, they truly have a superior product.
Disclaimer: I own shares of Riverbed.
[...] just upgraded WordPress and the process of doing so sucked. I blogged about it before. Upgrading WordPress is such a pain not because it is difficult, but because it’s a pain to [...]