私は、IIS がインストールされた 2 つの VM で Server2016 を実行しており、NLB を使用してトラフィックのバランスを取り、config/ssl を共有しています。アップロード速度は 256KB/秒 (2Mb) に制限されているようです。インターネット接続はギガビット ファイバーです。
問題を切り分けるために、いくつかのテストを実行しました。アップロード ボタンと送信ボタンを備えたシンプルな .net Web アプリを作成し、28 MB のファイルをアップロードしました。
IISボックスにアプリを置くとhttps://domain.tld/アップロードChrome 開発ツールによると、1.9 分かかりました。これは約 256 KB です。
私はVisual Studioを使用してこれを作成したので、デスクトップのWindows 10マシンでIIS Express経由でアプリを実行し、ルーターを介してランダムポートを開きました。アップロードには761ミリ秒かかりました。これは約37MB/秒です。
これらのテストを数回繰り返しましたが、ほぼ同じ結果になりました。同じボックスからアップロードとダウンロードを行っているため、実際には約 74 MB/秒、つまり理論上のギガビット アップロードとダウンロードのそれぞれ 30% を使用しています。したがって、これは ISP の問題ではないと思います。
また、NLB クラスターを分割してすべてのトラフィックを 1 つのボックスにルーティングしてみましたが、結果は同じでした。
IIS がなぜこんなに遅いのか、何か考えはありますか?
答え1
他にも興味がある人がいるかもしれないのでこれを投稿します...問題は NLB でした。
送信トラフィックの場合、大きな問題にはなりませんが、「適切に」動作させるにはネットワークの調整を行う必要があります。
- ユニキャスト: 両方のノードの MAC が同じ「クラスター」MAC アドレスに置き換えられているため、ネットワーク スイッチはルーティング テーブルを適切に更新できず、すべてのポートをフラッディングするため、正常に動作しなくなります。解決策としては、ハブを使用するか、別の VLAN を使用することです。
- マルチキャスト: 各ノードは MAC アドレスを保持し、追加のマルチキャスト MAC を取得します。スイッチは物理 NIC に接続されていないため MAC を「学習」できず、ユニキャストと同様にパケットをドロップするかフラッディングします。解決策は、ネットワークに静的 ARP および MAC エントリを追加することです。
- マルチキャスト IGMP: マルチキャストと同じですが、マルチキャストがどのように動作するかを「学習」できるように、IGMP 対応のスイッチが必要です。したがって、解決策はなく、動作するか動作しないかのどちらかです。
さらにテストを進めると、大きなファイルを IIS クラスターにアップロードすると、同じスイッチ上の他のマシン/VM でネットワーク パフォーマンスが著しく低下することがわかり、フラッディングの問題が確認されました。
私の職場環境では、ネットワーク担当者は、IGMP の有効化を含め、ネットワーク インフラストラクチャの変更に対して「ノー」と言いました。
高可用性のために 2 台のサーバーが必要だったので、代わりに、監視用の共有ディスクと IIS 共有構成および集中 SSL 用の共有ディスクを備えた 2 ノードのフェールオーバー クラスターを作成することにしました。アクティブ/アクティブではありませんが、パッチ適用中などに稼働時間を維持できます。IIS でクラスターを実行することは推奨されていないことは承知していますが、ハードウェア ロード バランサーや適切に構成できるネットワークがない場合は、これで十分です :)