.net - ejemplo - configurar iis express visual studio 2017

Cuando mi gran sitio ASP.NET se actualiza, IIS tiene que recompilar una gran cantidad. ¿Hay alguna forma de reducir significativamente mi tiempo de compilación?

Question

DotNetNuke es un gran CMS de ASP.NET que en su mayoría está precompilado, al igual que la mayoría de los módulos que contiene.

Cuando implementamos nuestros cambios en el sitio DotNetNuke, tenemos dos bits de recompilación que ocurren en el primer hit de la página.

1. Recopilación de nivel de aplicación que se produce cuando se reemplaza un archivo DLL en la carpeta bin
2. Cada vez que se accede a un módulo individual por primera vez, se produce una recompilación en ese módulo específico.

¿Hay alguna manera de asignar más capacidad de la CPU para compilar sitios asp.net en IIS 7?

• Me gustaría usar más de un núcleo, o al menos hacer algo para reducir el tiempo de recompilación.

Q & A

Debería usar ASP.NET precompilado. ¿Por qué no?

• Estamos utilizando ASP.NET precompilado. El hecho de que una aplicación ASP.NET esté compilada en un archivo DLL no significa que el tiempo de ejecución de ASP.NET no haga recompilación adicional para servirlo a los visitantes.

¿Cómo sabes que recompila y no completa el caché o algo así?

• La visualización del administrador de tareas en el servidor muestra un uso de CPU del 50% por parte del ejecutable del compilador durante los hits de página mencionados anteriormente. ¿Por qué 50%? Servidor de 2 núcleos

Answer 1

Estoy bastante seguro de que no es posible ya que la compilación se realiza en un único hilo, que no puede abarcar procesadores. La ejecución del sitio abarca procesadores / núcleos, pero la primera compilación de aciertos no lo hace.

Lo que puedes ver es dividir tu solución en proyectos. Entonces, una porción más pequeña de su sitio necesita una recompilación completa.

Answer 2

¿Es una opción la precompilación en lugar de la compilación dinámica?

Answer 3

El 50% de la utilización de la CPU en un sistema de CPU de 2 núcleos indica que el compilador ASP.NET tiene un solo subproceso. Habría visto una utilización de la CPU del 25% en un sistema de cuatro núcleos.
Según mi leal saber y entender, no existe una forma mágica de convertirlo en un compilador multiproceso.

Sin embargo, una cosa que podría hacer es usar la herramienta de compilación ASP.NET para precompilar todo el sitio antes de implementarlo. Haga esto en un cuadro dev / staging e impleméntelo para prod, y su implementación prod no debería sufrir estas demoras.

Debe morderme la lengua, pero tengo que preguntar; ¿Realmente se despliega para presionar con frecuencia que esto es un problema?

Answer 4

Set <compilation optimizeCompilations="true" />

Especifica si la compilación dinámica recompilará un sitio completo si se cambia un archivo de nivel superior. Los archivos de nivel superior incluyen el archivo Global.asax y todos los archivos en las carpetas Bin y App_Code. Si es True, solo se vuelven a compilar los archivos modificados.

Fuente: Elemento de compilación (Esquema de configuración de ASP.NET)

Puede encontrar más información sobre los pros y los contras en Comprender la compilación dinámica de ASP.NET , en Optimización de la compilación dinámica. La causa principal de los errores es la eliminación o los cambios en las firmas de métodos existentes, lo que hace que las páginas ya compiladas arrojen una excepción MissingMethodException hasta que se vuelvan a compilar.

También podría considerar reducir el tamaño del lote para la compilación de lotes, o deshabilitarlo por completo. Creo que esto reducirá los tiempos de compilación para páginas individuales, pero generará más ensamblajes y consumirá más memoria.

Answer 5

He tenido exactamente esta misma experiencia con DotNetNuke en el pasado. Nuestro problema era que teníamos aproximadamente 125-150 módulos instalados, todos con sus propios ensamblajes. El número total de ellos provocaría que la primera demora de solicitud sea cercana a un minuto o más. Fue peor durante el tiempo de implementación, ya que reinstalaríamos intencionalmente nuestros propios módulos personalizados. Más tarde, ajustamos los scripts de implementación para evitar la instalación de módulos ya instalados, y esto ayudó. Sin embargo, la primera solicitud todavía era un oso porque estaba ejecutando el compilador VB.NET y C # (nuestros módulos eran C # mientras DNN era VB.NET en ese momento).

Si bien utilizamos el atributo optimizeCompiliations para ayudarlo un poco, también debe considerar garantizar que no haya un explorador de virus en tiempo real que supervise tanto el directorio donde se encuentra el código como la carpeta Archivos temporales ASP.NET. Esto ralentizará la compilación a un rastreo.

A continuación, puede considerar usar ILMerge para fusionar algunos ensamblados en un solo ensamblaje, pero sé que evitamos esta opción ya que nos causaba más dolores de cabeza en la implementación de lo que iba a resolver.

Por último, este es un escenario en el que algo de hardware adicional no es una mala idea. Lo que más ayudará es una CPU más rápida solo para reducir el tiempo de compilación a un tiempo razonable.

DotNetNuke.com tiene algunas sugerencias de ajuste de rendimiento en su Wiki. El que más ayudó con el rendimiento en general fue truncar las tablas EventLog y SiteLog, ya que pueden ser muy grandes si no les presta atención. También hay una o dos tablas involucradas en la indexación del sitio que, en algunas versiones, crecieron fuera de control. Honestamente, este no es tu problema. Está teniendo el típico problema de arranque en frío de ASP.NET.

También hay algunos problemas de rendimiento de ASP.NET comunes en los que también debería considerar. Éste habla de mejoras de rendimiento tanto en frío como en caliente.