Sitio de IIS sobre el uso de UNC: ¿es problemático?

asp-classic netbios

Question

Estoy trabajando con una solución ASP Classic heredada que se carga equilibrada (a través de hardware externo y tiene un sitio IIS cuyo directorio principal es una ruta UNC. Me han dicho que existen los siguientes problemas con esta configuración actualmente:

1. Cuando se usa una ruta UNC como directorio de inicio, hay un "índice" en algún lugar de IIS que "almacena en caché" hasta una cierta cantidad de archivos de ciertos tipos, y cuando se alcanza el límite predeterminado de 50, las solicitudes posteriores a las páginas que no están en la memoria caché devolverán 404.
2. Al utilizar una ruta UNC como directorio principal, al iniciar el sitio IIS, la "memoria caché" mencionada comenzará a llenarse, lo que saturará el sitio IIS hasta que se llene la caché, lo que significa que los sitios enormes (15,000 archivos .asp) no estarán disponibles. hasta 30 minutos después de que comience el sitio de IIS.
3. Al utilizar una ruta UNC como directorio de inicio, si se realizan más de un cierto número de solicitudes simultáneas al sitio, Windows alcanzará el "límite de comando del BIOS de red por servidor" y todas las solicitudes que superen el límite deberán esperar hasta IIS ". cierra la sesión "al servidor. Me dijeron que el límite es de 100 archivos y no se puede configurar.

Ahora, todo esto suena un poco raro. Si configuro un nuevo servidor de Windows 2003 con la configuración predeterminada y lo uso para alojar una aplicación ASP Classic con 15,000 archivos .asp, usando un recurso compartido en un servidor como el directorio de inicio para el sitio de IIS, ¿realmente me encontraré con estos problemas? ? Y si es así, ¿hay alguna forma de contrarrestarlos sin cambiar la arquitectura?

(Para aclarar, la única razón por la que el "equilibrio de carga" es importante es que el equilibrio de carga es la razón por la cual los archivos están compartidos en un servidor. Si no se necesita balanceo de carga, los archivos podrían estar en el disco local).

Answer 1

No estoy seguro acerca de su pregunta directa sobre la interacción entre IIS y UNC, pero sugeriría en un sitio ocupado (todo lo suficientemente ocupado como para requerir el equilibrio de carga), que considere algo que no sea un archivo compartido.

Una asp cargada por IIS a través de una red (es decir, un recurso compartido de archivos) sufrirá implicaciones de rendimiento negativas (latencia).

Sugiero usar algo como robocopy para mantener sincronizados todos los servidores de carga balanceada con un maestro central. En otras palabras, impleméntelo en un solo servidor maestro (o ubicación maestra única), luego robocopé los archivos a cada esclavo en el grupo del equilibrador de carga.

Esto no solo eliminará los extraños problemas de UNC que usted describe, sino que también le dará un buen impulso al rendimiento (al eliminar el golpe de red al cargar páginas asp). Esperaría incrementos de rendimiento bastante pesados ​​si hicieras esto.

Answer 2

Para la respuesta 3, puede cambiar el límite de comando del BIOS de red. Es una corrección de edición de registro bastante sencilla: http://support.microsoft.com/kb/810886/en-us

Me he encontrado con ese problema en particular yo mismo.

Answer 3

Sí, es posible, pero sí, puede causar problemas.

Cuando ASP.NET compila ASPX, ASCX y otras páginas de contenido en ensamblajes, crea una gran cantidad de FileSystemWatchers para monitorear las dependencias entre ellos, de modo que cuando los archivos cambien, puedan recompilarse. Estos consumen recursos de NetBIOS.

Además, cada vez que hace una llamada File.Exists o Directory.Exists, o cualquier otro tipo de IO a la ruta de servicio del sitio, eso aumenta las demandas en los límites de NetBIOS también.

Es posible establecer los límites de NetBIOS a través del registro por encima de sus valores predeterminados a un punto.

Para un sitio pequeño, con relativamente pocos directorios y archivos, podría ejecutar con éxito un recurso compartido UNC porque ASP.NET continuará ejecutándose después del inicio fuera de sus ensamblados compilados. Sin embargo, cuantos más directorios y archivos agregue, más probabilidades habrá de que surjan problemas.

Intentamos ejecutar un sitio gigantesco (cientos de directorios y archivos ASPX / ASCX) y funcionaría bien durante unos minutos hasta que se accediera a las URL suficientes para alcanzar los límites de NetBIOS, y luego cada vista de página posterior generara una excepción. Terminamos forzados a usar una solución de publicación robocopy.

Al final, debe probar para ver si su sitio es lo suficientemente pequeño y su configuración de NetBIOS es lo suficientemente alta como para ejecutarse de manera efectiva. Sugeriría usar una araña en un sitio de prueba para que pueda estar seguro de que todo lo que se puede compilar o acceder es al menos una vez.