General Computing
iis
Updated Thu, 25 Aug 2022 21:16:28 GMT

Slow uploads on IIS 2016


I am running Server2016 in two VM's with IIS installed, using NLB to balance the traffic and shared config/ssl. My upload speeds seem limited to 256KB/s (2Mb). My internet connection is gigabit fiber.

I ran a few tests to try to isolate the issue. I created a simple .net web app with an upload and a submit button, and uploaded a 28MB file.

  • When I put the app on my IIS box at https://domain.tld/upload, it took 1.9 minutes according to chrome dev tools , which is roughly 256KB again.

  • I used visual studio to make it, so I just ran the app on my desktop win 10 machine via IIS express and opened up the random port through my router, and the upload took 761ms, which is roughly ~37MB/s

I repeated those tests a few times and got pretty much the same results. Given that I'm uploading and downloading from the same box, it's really using ~74MB/s-ish, or 30% of my theoretical gigabit upload and download each. So I feel like it's not an ISP issue.

I also tried breaking the NLB cluster and routing all traffic to just one box, same result.

Any ideas on why IIS is so slow?




Solution

Posting this in case anyone else is every curious.... the problem was NLB.

https://blogs.technet.microsoft.com/netgeeks/2017/07/13/the-nlb-deployment-reference-all-you-need-to-know-to-implement-and-deploy-microsoft-network-load-balancing/

For outbound traffic it's no big deal, but you need to do some network tweaks to make it work "properly".

  • Unicast: since both nodes have their MAC replaced with the same 'cluster' MAC address, your network switch will go nuts cause it can't properly update it's routing table and flood all ports. The solution is to use a hub or to use a separate vlan.
  • Multicast: each node retains it's MAC address and gets an additional multicast MAC. Switches can't 'learn' the MAC since it's not attached to the physical NIC, so they either drop the packets or flood just like unicast. The solution is to add static ARP and MAC entries in your network.
  • Mutlicast IGMP: Same as multicast, but instead it requires switches that are IGMP capable so they can 'learn' how your multicasting is supposed to work. So no solution, it will either work or it won't.

Upon further testing, when uploading a large file to our IIS cluster, we would see terrible network performance on other machines/VMs on the same switch, so this would seem to confirm the flooding problem.

In my particular situation, in my work environment, the network peeps said "nope" to any network infrastructure changes, including enabling IGMP.

We just wanted two servers for high availability, so we decided to instead create a two node failover cluster with a shared disk for a witness and a shared disk for IIS shared config and centralized SSL. It's not active-active, but we can maintain uptime while patching, etc. I know it's not recommended for IIS to do a cluster, but in the absence of a hardware load balancer or a network you can configure properly, this will have to do :)