Erik Brooks

 
We were downloading in London from a Domino server in Florida. Domino was serving the file at a whopping 65K/sec to London, despite being on a connection with about 8 MB upstream available and the London connection having tons of available downstream bandwidth. Running an FTP server on the same machines allowed the same file to be transferred at about 600K/sec.
 
HTTP transfers are slower than FTP but not that much slower. So we opened a PMR. The answer is this SPR on Windows:
 

SPR # MKIN7TGMQV    Fixed in release: 8.0.2 FP3, 8.5.1
Product Area: Server  Technical Area: Web Server  Platform: Windows
Lotus Customer Support APAR:  LO45289  What is an APAR?

SPR# MKIN7TGMQV - Fix for Windows, where we had  performance problem on high latency networks. We added/changed code to reduce latencies by changing how the winsock layer is used and by increasing the buffer size of network writes.

 
Apparently Microsoft changed the Winsock layer interface when they released Windows Server 2003 but didn't tell anybody. The old interface (which IBM was using) became worse while the new one was the latest-and-greatest (which IIS, surprise surprise, was using.) The end result is that a user's transfer speed was heavily influenced by their latency.  E.g. with 60ms of latency you might get 240K/sec.  With 80ms of latency you might get 180K/sec. And in our case (160ms or so) we were getting 65K/sec.
 
Installing a hotfix for this SPR brought that server's HTTP transfer speed up to around 400-450K/sec to London.
 
While this fix is great and all, the scary bit here for me is that IBM didn't notice this until 8.5.1, so sometime in 2009... about 6 years after Windows 2003 shipped. I hope that a high-latency network model is part of their test suite now.