¿Cuántos Application Pool debo tener?
No es la primera vez que me preguntan cuántos application pools tienen que crear. Y la respuesta que podemos dar es ambigua.
No hay una norma estricta que establezca cuántos Working Process se deben tener, aunque sí que es recomendable separarlos por Web Site y por grupo de aplicaciones. De tal modo que se aíslen las aplicaciones que puedan tener relación unas con otras.
Si por ejemplo tenemos todos los sitios web y aplicaciones utilizando el mismo Application Pool, como he dicho antes, no tiene que ser una mala práctica, pero puede generar conflictos ya que cualquier incidencia de rendimiento o de crash de la aplicación afecta a las demás.
Si todas las aplicaciones están contenidas en el mismo Application Pool y una de esas aplicaciones genera una excepción no controlada, como una violación de acceso o corrupción en el stack o en el heap, puede provocar que todo el Working process (w3wp.exe) finalice, terminando así con todas las aplicaciones y web sites en ejecución. Lo que hace que una excepción de este tipo en un Web Site haga que los usuarios de otro Web Site totalmente independiente a este se vean afectados. Del mismo modo, si una aplicación "cuelga" el proceso, todos las demás aplicaciones serían afectados
También puede afectar al rendimiento, ya que en una arquitectura x86 el tamaño máximo que puede gestionar un proceso es de unos 4GB, 2 de ellos quedando reservados para memoria propia del sistema operativo (kernel). Lo que nos dejaría 2GB para alojar todos los procesos (independientemente de la memoria virtual y RAM disponibles). Una vez alcanzados esos 2 GB, se provocará una excepción de SystemOutOfMemory y todo el proceso finalizaría con las consecuencias anteriormente descritas. En el caso de que se ejecute un proceso de 32 bits en una arquitectura x64, puede llegar a utilizar los 4GB.
Tenemos que tener en cuenta que por defecto un proceso tiene 12 working threads por procesador, por lo que sólo ejecutará 12 peticiones simultáneamente. Así que si agrupamos muchas aplicaciones en un mismo working process las aplicaciones compartirán esos 12 threads. Así que una forma de aumentar el número de threads que va a utilizar la aplicación (con el coste en consumo de CPU que conlleva) el separar las aplicaciones en distintos Application Pools
Otro inconveniente es que no se pueden tener versiones diferentes del Framework de .NET en el mismo Working process, por lo que se limita a que todas las aplicaciones utilicen la misma versión de .NET.
Como resumen, os indicaría que valoréis bien el aislamiento que queréis darle a las aplicaciones y el crecimiento que pueden tener y que os baséis en las indicaciones que os he comentado. Eso os dará la idea de cuántos Application Pools debes tener.
Espero que os sirva de ayuda
- José Ortega Gutiérrez