Я запускаю Server2016 на двух виртуальных машинах с установленным IIS, использую NLB для балансировки трафика и общую конфигурацию/ssl. Моя скорость загрузки, похоже, ограничена 256 КБ/с (2 Мб). Мое интернет-соединение — гигабитное оптоволокно.
Я провел несколько тестов, чтобы попытаться изолировать проблему. Я создал простое веб-приложение .net с кнопкой загрузки и отправки и загрузил файл размером 28 МБ.
Когда я установил приложение на свой компьютер IIShttps://domain.tld/upload, по данным Chrome Dev Tools, это заняло 1,9 минуты, что снова составляет примерно 256 КБ.
Для этого я использовал Visual Studio, поэтому просто запустил приложение на своем настольном компьютере с Win 10 через IIS Express и открыл случайный порт через свой маршрутизатор. Загрузка заняла 761 мс, что примерно составляет ~37 МБ/с.
Я повторил эти тесты несколько раз и получил примерно те же результаты. Учитывая, что я загружаю и скачиваю с одного и того же устройства, оно на самом деле использует ~74 МБ/с или 30% от моего теоретического гигабита на загрузку и скачивание. Так что я думаю, что это не проблема провайдера.
Я также пробовал разбить кластер NLB и направить весь трафик только на один сервер, результат тот же.
Есть идеи, почему IIS такой медленный?
решение1
Публикую это на случай, если кому-то еще интересно... проблема была в NLB.
Для исходящего трафика это не имеет большого значения, но вам нужно будет выполнить некоторые настройки сети, чтобы все работало «правильно».
- Unicast: поскольку оба узла заменили свой MAC на тот же самый «кластерный» MAC-адрес, ваш сетевой коммутатор сойдет с ума, так как он не сможет должным образом обновить свою таблицу маршрутизации и заполнит все порты. Решение — использовать концентратор или использовать отдельную vlan.
- Multicast: каждый узел сохраняет свой MAC-адрес и получает дополнительный multicast MAC. Коммутаторы не могут «узнать» MAC, поскольку он не подключен к физической сетевой карте, поэтому они либо сбрасывают пакеты, либо рассылают их так же, как и unicast. Решение заключается в добавлении статических записей ARP и MAC в вашу сеть.
- Multicast IGMP: то же самое, что и multicast, но вместо этого требуются коммутаторы, поддерживающие IGMP, чтобы они могли «узнать», как должна работать ваша multicasting. Так что решения нет, либо будет работать, либо нет.
При дальнейшем тестировании при загрузке большого файла в наш кластер IIS мы увидели ужасную производительность сети на других машинах/виртуальных машинах на том же коммутаторе, так что это, по-видимому, подтверждает проблему переполнения.
В моей конкретной ситуации, в моей рабочей среде, сетевые контроллеры сказали «нет» любым изменениям сетевой инфраструктуры, включая включение IGMP.
Мы просто хотели два сервера для высокой доступности, поэтому решили вместо этого создать двухузловой отказоустойчивый кластер с общим диском для свидетеля и общим диском для общей конфигурации IIS и централизованного SSL. Это не активный-активный, но мы можем поддерживать бесперебойную работу при исправлении и т. д. Я знаю, что не рекомендуется для IIS делать кластер, но при отсутствии аппаратного балансировщика нагрузки или сети, которую можно правильно настроить, это придется сделать :)