Estoy ejecutando Server2016 en dos máquinas virtuales con IIS instalado, usando NLB para equilibrar el tráfico y la configuración/ssl compartida. Mis velocidades de carga parecen limitadas a 256 KB/s (2 Mb). Mi conexión a internet es fibra gigabit.
Realicé algunas pruebas para intentar aislar el problema. Creé una aplicación web .net simple con un botón de carga y envío, y cargué un archivo de 28 MB.
Cuando coloco la aplicación en mi caja IIS enhttps://dominio.tld/upload, tomó 1,9 minutos según las herramientas de desarrollo de Chrome, lo que nuevamente equivale aproximadamente a 256 KB.
Utilicé Visual Studio para hacerlo, así que simplemente ejecuté la aplicación en mi computadora de escritorio con Windows 10 a través de IIS Express y abrí el puerto aleatorio a través de mi enrutador, y la carga tomó 761 ms, lo que equivale aproximadamente a ~37 MB/s.
Repetí esas pruebas varias veces y obtuve prácticamente los mismos resultados. Dado que estoy cargando y descargando desde el mismo cuadro, en realidad está usando ~74MB/s-ish, o el 30% de mi carga y descarga teórica de gigabits cada una. Entonces siento que no es un problema de ISP.
También intenté romper el clúster NLB y enrutar todo el tráfico a un solo cuadro, y obtuve el mismo resultado.
¿Alguna idea de por qué IIS es tan lento?
Respuesta1
Publicar esto en caso de que alguien más tenga curiosidad... el problema fue NLB.
Para el tráfico saliente no es gran cosa, pero es necesario realizar algunos ajustes en la red para que funcione "correctamente".
- Unicast: dado que ambos nodos reemplazan su MAC con la misma dirección MAC de 'clúster', su conmutador de red se volverá loco porque no puede actualizar adecuadamente su tabla de enrutamiento e inundará todos los puertos. La solución es utilizar un concentrador o utilizar una VLAN independiente.
- Multidifusión: cada nodo conserva su dirección MAC y obtiene una MAC de multidifusión adicional. Los conmutadores no pueden "aprender" la MAC ya que no está conectada a la NIC física, por lo que descartan los paquetes o los inundan como si fueran unidifusión. La solución es agregar entradas ARP y MAC estáticas en su red.
- Mutlicast IGMP: Igual que la multidifusión, pero requiere conmutadores que sean compatibles con IGMP para que puedan "aprender" cómo se supone que funciona la multidifusión. Entonces no hay solución, funcionará o no.
Tras realizar más pruebas, al cargar un archivo grande en nuestro clúster IIS, veríamos un rendimiento de red terrible en otras máquinas/VM en el mismo conmutador, por lo que esto parecería confirmar el problema de inundación.
En mi situación particular, en mi entorno de trabajo, los espías de la red dijeron "no" a cualquier cambio en la infraestructura de la red, incluida la habilitación de IGMP.
Solo queríamos dos servidores para alta disponibilidad, por lo que decidimos crear un clúster de conmutación por error de dos nodos con un disco compartido para un testigo y un disco compartido para la configuración compartida de IIS y SSL centralizado. No es activo-activo, pero podemos mantener el tiempo de actividad mientras aplicamos parches, etc. Sé que no se recomienda que IIS cree un clúster, pero en ausencia de un equilibrador de carga de hardware o una red que pueda configurar correctamente, esto tendrá que ser suficiente. :)