En ASP.NET Core Dependency Injection, me pregunto si el registro de instancias Singleton mejorará el rendimiento en lugar de registrar instancias Transient o no.
En mi opinión, para la instancia de Singleton , solo cuesta una vez crear un nuevo objeto y objetos dependientes. Para la instancia Transient , este costo se repetirá para cada solicitud de servicio. Entonces Singleton parece ser mejor. Pero, ¿cuánto rendimiento ganamos cuando usamos Singleton sobre Transient ? ¡Gracias de antemano!
Sé que el rendimiento aquí no es lo que deberías buscar, pero por curiosidad, hice una aplicación de referencia de muestra para evaluar la diferencia entre AddSingleton y AddTransient, usando BenchmarkDotNet
La solución que utilicé se puede encontrar aquí (no dude en mejorarla): https://github.com/iheb719/BenchmarkDifferentServicesInstances
Este fue mi resumen:
Especificaciones de mi computadora portátil: BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19042.1415 (20H2/October2020Update) Intel Core i7-9750H CPU 2.60GHz, 1 CPU, 12 núcleos lógicos y 6 físicos .NET SDK=6.0.101 [Host]: .NET 6.0.1 (6.0.121.56705), X64 RyuJIT Trabajo predeterminado: .NET 6.0.1 (6.0.121.56705), X64 RyuJIT
Mis resultados :
| Método | Significar | Error | Desv.estándar |
|---|---|---|---|
| CallSingletonApp | 101.0 nosotros | 0.64 nosotros | 0.53 nosotros |
| CallTransientApp | 108.3 nosotros | 1.16 nosotros | 1.03 nosotros |
Entonces, realmente no hay una diferencia significativa entre AddSingleton y AddTransient (por supuesto, si no tiene grandes tratamientos dentro de sus constructores)
Como se mencionó en las respuestas, esto no es realmente una cuestión de rendimiento.
Para obtener más detalles, consulte el enlace a continuación, donde se explica detalladamente la diferencia. Diferencias de los servicios AddTransient, AddScoped y AddSingleton
La única forma en que esto importará en cuanto al rendimiento es si su constructor está haciendo muchas cosas. Sin embargo, esto puede y debe evitarse en todos los casos.
Como han dicho otros, el rendimiento no debe tomar su decisión aquí: el rendimiento no se verá afectado drásticamente de ninguna manera. Lo que debe tener en cuenta son las dependencias, tanto administradas como no administradas. Los singletons son mejores cuando utiliza recursos limitados, como sockets y conexiones. Si termina teniendo que crear un nuevo socket cada vez que se inyecta el servicio (transitorio), rápidamente se quedará sin sockets y el rendimiento realmente se verá afectado.
El ámbito transitorio es mejor cuando el uso de recursos es temporal y tiene un impacto mínimo. Si solo está haciendo cálculos, por ejemplo, eso puede tener un alcance transitorio porque no está agotando nada al tener varias copias.
También desea utilizar el alcance singleton cuando el estado es importante. Si algo necesita persistir más allá de una operación en particular, entonces transitorio no funcionará, porque no tendrá estado, porque esencialmente comenzará de nuevo cada vez que se inyecte. Por ejemplo, si estuviera tratando de coordinar una cola concurrente, usando semáforos para bloqueos, entonces definitivamente querrá un servicio de alcance único. Si el estado no importa, entonces transitorio es probablemente el mejor alcance.
Finalmente, debe buscar otros servicios de los que depende su servicio. Si necesita acceso a servicios con ámbito (como cosas que tienen un ámbito de solicitud), entonces un singleton es una mala opción. Si bien es posible que pueda usar un patrón de localizador de servicios para acceder a los servicios del ámbito, es un paso en falso y no se recomienda. Básicamente, si su servicio usa algo más que otros servicios singleton, probablemente debería tener un alcance o ser transitorio.
Largo y corto, use un alcance transitorio a menos que tenga una razón buena y explícita para convertirlo en un singleton. Esas serían razones como las mencionadas anteriormente: mantener el estado, utilizar recursos limitados de manera eficiente, etc. Si el servicio funcionará en un ámbito transitorio y no hay una buena razón para hacerlo de otra manera, utilice el ámbito transitorio.
Ahora, la DI de ASP.NET Core tiene una vida útil "transitoria" y "de alcance". Ambos son "transitorios" en el sentido de que van y vienen, pero "alcance" se instancia una vez por "ámbito" (generalmente una solicitud), mientras que "transitorio" siempre se instancia cada vez que se inyecta. Aquí, debe usar "alcance" a menos que tenga una buena razón explícita para usar "transitorio".