Estamos en el proceso de implementar una nueva aplicación en su entorno en vivo.
Los servidores de aplicaciones ejecutan una aplicación .NET alojada en IIS que utiliza EntityFramework y realiza numerosas llamadas a una aplicación COM+ que no es .NET.
Hemos podido afectar el rendimiento del código .NET puro modificando el número máximo de procesos de trabajo dentro del grupo de aplicaciones IIS, pero mi pregunta es cómo se relaciona el número de procesos de trabajo con el tamaño del grupo de aplicaciones en los servicios de componentes. ? Cosas como:
- ¿Deberíamos aspirar a una relación 1 a 1 entre estos 2 valores?
- ¿Deberíamos evitar múltiples subprocesos de trabajo?
Cualquier idea recibida con gratitud...
Respuesta1
La cantidad de procesos de trabajo en los dos grupos no está directamente relacionada. Lo que hay que establecer es el tiempo de permanencia en cada piscina. Por lo tanto, si los trabajadores de IIS están ocupados y sólo una pequeña proporción del tiempo total se dedica a la aplicación COM, entonces no es probable que los subprocesos COM obstaculicen el rendimiento.
Intente medir la cantidad de subprocesos activos en una situación de estrés para determinar cómo controlar los tamaños de los grupos individuales.
Considere también que los procesos de trabajo de IIS también se reciclan según criterios distintos de la utilización del procesador. Esto puede afectar sustancialmente su capacidad para compartir datos entre invocaciones y podría subvertir los intentos de afectar fuertemente el rendimiento directo.
Sería mejor para reducir el costo de realizar el puente .NET a COM considerando un contenedor COM delgado que pueda agregar múltiples solicitudes desde una única consulta .NET. Esto también puede tener el efecto secundario de consolidar múltiples métodos COM en un solo subproceso del grupo.