Desarrollador .NET: pregunta de entrevista
¿Cómo diagnosticas un servicio .NET lento?
Correlaciona latencia y throughput .NET con trazas, revisa agotamiento del thread pool, GC y asignaciones con dotnet-counters o traces, perfila rutas, comprueba base de datos y mide la corrección.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
La investigación sigue la evidencia de fuera hacia dentro. Las métricas y trazas de solicitudes identifican qué endpoints son lentos y si el tiempo está en la aplicación, la base de datos o una llamada externa. dotnet-counters muestra en tiempo real la longitud de la cola del pool de hilos y la inanición, la frecuencia de GC y la tasa de asignación; dotnet-trace o un profiler continuo atribuyen la CPU a métodos bajo carga de producción. El tiempo de base de datos se revisa con el logging de EF Core y los planes de consulta. El arreglo apunta al coste dominante, y BenchmarkDotNet o una prueba de carga con la misma mezcla de solicitudes lo confirma antes de publicar.
Ejemplo
Una API con latencia creciente mostraba en dotnet-counters una cola del pool de hilos en aumento; una traza encontró una llamada síncrona .Result en una ruta caliente que bloqueaba hilos mientras esperaba a Redis. Hacer la ruta totalmente asíncrona bajó el p95 de 900 ms a 120 ms sin cambiar hardware, y una traza posterior encontró una consulta LINQ que materializaba una tabla entera para filtrarla en memoria.
Errores frecuentes
- Aumentar el mínimo de hilos para enmascarar el sync-over-async en lugar de arreglarlo.
- Optimizar un método que el profiler nunca señaló.
- Medir con caché caliente y base de datos vacía y sorprenderse en producción.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.