我在兩個安裝了 IIS 的虛擬機器中執行 Server2016，使用 NLB 來平衡流量和共用配置/ssl。我的上傳速度似乎限制為 256KB/s (2Mb)。我的網路連線是千兆光纖。
我進行了一些測試來嘗試找出問題所在。我創建了一個簡單的 .net Web 應用程序，其中包含上傳和提交按鈕，並上傳了一個 28MB 的檔案。
當我將應用程式放在我的 IIS 盒子上時https://domain.tld/upload，根據 Chrome 開發工具，花了 1.9 分鐘，大約又是 256KB。
我使用 Visual Studio 來製作它，所以我只是透過 IIS Express 在我的桌面 Win 10 機器上運行該應用程序，並透過我的路由器打開隨機端口，上傳花費了 761 毫秒，大約約為 37MB/s
我重複了這些測試幾次，得到了幾乎相同的結果。考慮到我從同一個盒子上傳和下載，它實際上使用了約 74MB/秒，或者說是我理論千兆位元上傳和下載的 30%。所以我覺得這不是ISP的問題。
我還嘗試破壞 NLB 叢集並將所有流量路由到一個盒子，結果相同。
關於 IIS 為何如此緩慢的任何想法？
答案1
發布此內容以防其他人好奇......問題是 NLB。
對於出站流量來說，這沒什麼大不了的，但您需要進行一些網路調整以使其「正常」工作。
- 單播：由於兩個節點的 MAC 都被替換為相同的「叢集」MAC 位址，因此您的網路交換器將會發瘋，因為它無法正確更新其路由表並淹沒所有連接埠。解決辦法是使用集線器或使用單獨的vlan。
- 多播：每個節點保留其 MAC 位址並獲得額外的多播 MAC。交換器無法「學習」MAC，因為它沒有連接到實體網路卡，因此它們要么丟棄資料包，要么像單播一樣進行泛洪。解決方案是在網路中新增靜態 ARP 和 MAC 條目。
- 多播 IGMP：與多播相同，但它需要具有 IGMP 功能的交換機，以便它們可以「了解」多播應該如何運作。所以沒有解決辦法，要嘛有效，要嘛無效。
經過進一步測試，當將大檔案上傳到我們的 IIS 叢集時，我們會在同一交換器上的其他電腦/虛擬機器上看到糟糕的網路效能，因此這似乎證實了洪水問題。
在我的特定情況下，在我的工作環境中，網路窺探者對任何網路基礎設施變更（包括啟用 IGMP）說「不」。
我們只需要兩台伺服器來實現高可用性，因此我們決定創建一個兩節點故障轉移集群，其中一個用於見證伺服器的共享磁碟，一個用於 IIS 共享配置和集中式 SSL 的共享磁碟。它不是主動-主動的，但我們可以在打補丁等的同時維持正常運行時間。做:)