Rendimiento y perfilado
Las aplicaciones rápidas conservan a sus usuarios, y a gran escala el rendimiento es un problema de arquitectura, no algo que se deja para el final. Este curso te enseña a medir, perfilar y optimizar aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas bajo carga. Aprenderás a encontrar cuellos de botella con un perfilado real, a entender en qué se van el tiempo de servidor y la memoria de cada sesión, y a aplicar las técnicas que mantienen ágil una aplicación Wisej.NET muy concurrida a gran escala.
Mide, perfila y optimiza aplicaciones Wisej.NET: encuentra los cuellos de botella y mantén las sesiones rápidas a escala.
- Nivel: Advanced
- Duración: 9 h
- Módulos: 7
Temario
Módulo 1: El modelo de rendimiento de Wisej.NET
Módulo 1 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre el modelo de rendimiento, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
El ciclo de peticiones y eventos, el push por WebSocket, el estado de sesión como unidad de capacidad, los cinco grupos de coste y la disciplina de escenario más línea base con la que se compara cada traza posterior. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoDónde se va realmente el tiempo en una sesión de Wisej.NET · 14 min
Dónde se va realmente el tiempo en una sesión de Wisej.NET: un recorrido guiado del Módulo 1, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Comience con la actualización lenta en WisejPerfLab. El tiempo transcurrido establece el problema, pero una investigación útil debe explicar dónde pasó ese tiempo antes de elegir una solución.
Siga el clic desde el navegador al servidor y viceversa. Los controles del servidor consumen memoria, mientras que cambiarlos también genera trabajo de procesamiento, transporte y renderizado.
Cálculo separado, espera, memoria, acceso a datos y actualizaciones transmitidas. Esta clasificación determina qué medida puede explicar el retraso; un seguimiento del procesador no puede revelar el costo de cada navegador.
Agregue un ScenarioProbe alrededor de la acción. Un alcance desechable registra la finalización de cada ruta de salida, y los campos de duración con nombre y recuento de filas hacen que las ejecuciones separadas sean comparables.
Cuente los objetos retenidos por cada sesión, incluidos los controles y las filas almacenadas en caché. Una pequeña fuga se convierte en un problema de capacidad cuando cada sesión conectada guarda otra copia.
Mida la consulta y los cambios de la interfaz juntos. De lo contrario, la duración registrada omite parte del trabajo que el usuario realmente espera durante la actualización.
Registre la actualización, la búsqueda y la expansión del árbol por separado en la aplicación calentada. Estos tiempos de sesión única son puntos de referencia; todavía no explican el comportamiento bajo el uso concurrente.
Anote la construcción, el conjunto de datos y el calentamiento junto a cada línea de base. Asigne a cada escenario un objetivo y una herramienta de medición para que las mejoras posteriores puedan evaluarse de manera consistente.
Instrumente los tres escenarios de laboratorio antes de optimizarlos. La línea de base y el presupuesto se convierten en la evidencia utilizada por los módulos posteriores para distinguir una mejora de un cambio de tiempo inexplicable.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 1 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Escenarios, sondas y el primer presupuesto · 45 min
Objetivo: Crea la solución WisejPerfLab con un dashboard de soporte, un grid de tickets y un árbol de clientes alimentados con datos de prueba, y hazla medible. Añade un servicio ScenarioProbe que envuelva un escenario en un ámbito Stopwatch y escriba logs PERF estructurados de inicio y fin con el nombre del escenario, la acción del usuario, los milisegundos transcurridos y el número de filas; regístralo en el host builder y envuelve con él tres escenarios: la actualización del dashboard, la búsqueda de tickets y la expansión del árbol de clientes. Ejecuta cada escenario una vez para calentar, luego registra la línea base y escribe un presupuesto de rendimiento que indique el entorno, la configuración de compilación, el tamaño del conjunto de datos y un umbral de aceptación por escenario. Entregables: Solución WisejPerfLab con dashboard, grid de tickets y árbol de clientes sobre datos de prueba; Servicio ScenarioProbe que escribe logs PERF estructurados de inicio y fin con milisegundos transcurridos y número de filas; Tres escenarios instrumentados: actualización del dashboard, búsqueda de tickets y expansión del árbol de clientes; Nota de línea base que registra entorno, configuración de compilación, tamaño del conjunto de datos y procedimiento de calentamiento; Presupuesto de rendimiento con un umbral de aceptación por escenario y la herramienta que demostraría cada uno.
Módulo 2: Flujo de trabajo de perfilado de Visual Studio para Wisej.NET
Módulo 2 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre el flujo de profiling, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
Ejecutar el Performance Profiler contra una aplicación Wisej.NET de la forma correcta: compilaciones Release sin el depurador, la matriz de selección de herramientas, conectarse a dotnet o w3wp, y leer la línea de tiempo del resumen, el árbol de llamadas, la ruta crítica y las vistas de llamadores/llamados. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoRecoge una traza que realmente demuestre algo · 14 min
Recoge una traza que realmente demuestre algo: un recorrido guiado del Módulo 2, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Una captura de perfiles es útil sólo cuando representa un experimento conocido. Mantenga explícita la compilación, el escenario y la herramienta seleccionada para que otro desarrollador pueda interpretar el resultado.
Ejecute primero una compilación Release hasta completar el calentamiento de la aplicación. Después registre una sola acción y detenga la captura. Excluir el arranque y la actividad no relacionada evita atribuir sus costes al comportamiento que está investigando.
Elija el generador de perfiles del costo sospechoso. El muestreo explica el cálculo; la espera, las asignaciones, el acceso a la base de datos y las operaciones de archivos necesitan diferentes vistas para exponer su contribución.
Prepare la nota de seguimiento antes de grabar. El alojamiento, el conjunto de datos, el navegador y el presupuesto explican las condiciones detrás de las muestras y hacen que la captura sea reproducible más adelante.
Adjunte al proceso que realmente atiende la solicitud. Confirme su identificador, especialmente cuando varios sitios o grupos de aplicaciones crean procesos con el mismo nombre ejecutable.
Seleccione el intervalo de clic antes de seguir la ruta activa. El tiempo inclusivo grande en el código de envío difiere del tiempo propio en FormatRow, donde realmente ocurre el trabajo del procesador.
Repita el mismo flujo de trabajo ordenado para cada captura. En Internet Information Services, seleccionar el proceso de trabajo incorrecto invalida las mediciones incluso antes de que comience el análisis.
Compare el muestreo con la instrumentación para la misma actualización. Las llamadas al formateador explican el cálculo, mientras que la espera separada muestra por qué una investigación sólo del procesador dejaría parte del retraso sin explicación.
Guarde ambos seguimientos de actualización con sus notas. Indique una causa sospechada y evidencia que la refutaría, de modo que el próximo cambio pruebe una hipótesis en lugar de una suposición.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 2 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Uso de CPU y trazas de instrumentación · 45 min
Objetivo: Perfila como es debido la lenta actualización del dashboard de WisejPerfLab. Cambia a Release, calienta la aplicación una vez y recoge una traza de CPU Usage de ese único escenario con Alt+F2; acota la línea de tiempo del resumen al propio clic y usa Show Hot Path para encontrar la ruta principal por debajo de los frames de despacho de Wisej.NET. Recoge una segunda traza de Instrumentation del mismo escenario para obtener el número de llamadas y el tiempo de reloj, decide a partir de las dos trazas si el coste es CPU dentro de tu código o tiempo de espera, y guarda ambos archivos .diagsession con un nombre que incluya el módulo, el escenario, la compilación, el conjunto de datos y la marca de tiempo. Entregables: Traza de CPU Usage en Release del escenario de actualización del dashboard, con la línea de tiempo acotada al clic; Captura de la ruta crítica que nombra la función principal de la aplicación y su CPU propia frente a la total; Traza de Instrumentation del mismo escenario con número de llamadas y tiempo de reloj; Nota de traza que indica curso, módulo, escenario, compilación, alojamiento, herramienta, navegador y presupuesto esperado; Causa raíz sospechada en un párrafo que diga a cuál de los cinco grupos de coste apunta la evidencia.
Módulo 3: Rutas críticas de CPU, controladores de eventos y trabajo de interfaz en el servidor
Módulo 3 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre las rutas críticas de CPU, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
Código de interfaz costoso en el servidor dentro de controladores de eventos, temporizadores, refrescos de layout y lógica de formato, y los patrones de caché, agrupación y view model que vuelven a hacer barato un clic. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoHaz que el botón Refresh sea barato · 14 min
Haz que el botón Refresh sea barato: un recorrido guiado del Módulo 3, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Comience con los infractores medidos: formateo de filas repetidas y reconstrucción del panel indicador. Sus patrones de llamada nos dicen qué trabajo eliminar del clic del usuario.
Busque operaciones que de otro modo serían razonables y que se repiten dentro de eventos frecuentes. El formateo, la conversión de imágenes, la reflexión y la clasificación se vuelven costosos cuando su ubicación multiplica el trabajo.
Distinga demasiadas llamadas de demasiado trabajo por llamada. La reducción de la frecuencia aborda el primer problema; abaratar una operación soluciona la segunda.
Inspeccione el controlador antes de cambiarlo. Reconstruir los controles y formatear todas las filas introduce costos diferentes, por lo que una única reescritura cosmética dejaría intacto el comportamiento subyacente.
Calcule previamente resultados estables, cambios relacionados con lotes y actualice los controles existentes. Almacenar en caché solo datos inmutables; mover el cálculo a un método asincrónico no elimina ese cálculo.
Mueva el formato a GetSnapshot y deje que el controlador asigne los resultados. Mantenga el alcance de medición original y restaure el botón en finally para que las fallas dejen la interfaz utilizable.
Repita la misma captura e inspeccione las llamadas, no solo el tiempo transcurrido. El formateador que desaparece de la ruta activa demuestra que el trabajo previsto realmente se eliminó.
La actualización ahora cumple con su presupuesto, pero documenta la obsolescencia de las instantáneas como compensación. La espera identificada por separado sigue siendo un problema diferente para una investigación posterior.
Reemplace ambos patrones costosos en el laboratorio y envíe mediciones comparables. Su evidencia debe conectar la instantánea y el controlador por lotes con los recuentos de llamadas modificados.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 3 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — De la ruta crítica a un view model en caché · 45 min
Objetivo: Arregla el botón Refresh de WisejPerfLab. Perfila el escenario de actualización con CPU Usage, abre el flame graph y Show Hot Path, e identifica a los dos culpables: un formateador que se ejecuta por celda en cada actualización y una reconstrucción de controles que vuelve a crear el panel de KPI cada vez. Sustitúyelos por un view model DashboardSnapshot cuyas cadenas de presentación se calculan una sola vez en el servicio, modifica las etiquetas y el origen de datos del gráfico una sola vez dentro de un ámbito de sonda en lugar de fila por fila, y mantén el botón desactivado en un try/finally mientras se ejecuta el trabajo. Vuelve a ejecutar el mismo escenario y captura la nueva ruta crítica. Entregables: Traza de CPU Usage «antes» que nombra el formateador repetido y la reconstrucción de controles con su CPU total y propia; View model DashboardSnapshot con las cadenas de presentación precalculadas en el servicio; Controlador de actualización agrupado que modifica los controles una sola vez dentro de un ámbito de sonda y reactiva el botón con try/finally; Traza de CPU Usage «después» del mismo escenario con la nueva ruta crítica; Tabla antes/después de CPU total, función principal y número de llamadas, más el riesgo restante.
Módulo 4: Memoria, asignaciones y fugas de sesión
Módulo 4 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre la memoria y las fugas, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
Presión de asignación frente a memoria retenida, el flujo de comparación de snapshots, los patrones de retención de Wisej.NET (eventos estáticos, temporizadores, tareas en segundo plano, cachés globales) y la lista de comprobación de liberación que demuestra que una fuga ha desaparecido. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoEncuentra el formulario que nunca se fue · 14 min
Encuentra el formulario que nunca se fue: un recorrido guiado del Módulo 4, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Una actualización rápida no demuestra un uso saludable de la memoria. Abrir y cerrar repetidamente un formulario revela si los objetos desaparecen cuando termina su vida visible.
Mida la asignación y la retención por separado. Los objetos temporales crean trabajo de colección, mientras que los objetos que permanecen accesibles consumen capacidad mientras sus referencias sobrevivan.
Tome una instantánea de la línea de base cálida, repita cincuenta ciclos, vuelva al modo inactivo y compare. La repetición hace que el crecimiento persistente sea más fácil de distinguir de las asignaciones temporales ordinarias.
Siga las referencias de los formularios supervivientes. Un evento estático y una devolución de llamada del temporizador mantienen el formulario accesible incluso después de que se cierra la ventana.
Inspeccione eventos, temporizadores, tareas, cachés, campos y enlaces en busca de referencias con vidas útiles más largas. La limpieza debe liberar la propiedad cuando la sesión o el formulario ya no los necesite.
Coloque la baja y la eliminación al lado de la gestión de por vida del formulario. Marcar IsDisposed evita trabajos no válidos, pero no libera la referencia que mantiene vivo ese formulario.
Compare las asignaciones de búsqueda después de proyectar los datos una vez. El volumen reducido de la cuerda demuestra un trabajo menos repetido durante los volver a dibujar, independientemente de si algún objeto tuvo fugas.
Repita los mismos cincuenta ciclos después de la limpieza. Confirme que tanto el recuento de formularios retenidos como la ruta de referencia desaparezcan; cualquiera de las dos comprobaciones por sí sola deja la explicación incompleta.
Envíe las pruebas de asignación y retención por separado. Utilice la cifra de memoria por sesión resultante para establecer un presupuesto de capacidad que las comprobaciones de implementación posteriores puedan aplicar.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 4 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Presión de asignación y raíces de retención · 45 min
Objetivo: Ataca las dos mitades del problema de memoria en WisejPerfLab. Ejecuta el escenario de búsqueda de tickets con .NET Object Allocation, encuentra los modelos de fila y las cadenas asignadas en cada búsqueda y redúcelos proyectando una sola vez en lugar de reconstruir objetos en cada redibujado. Después toma un snapshot de Memory Usage tras el calentamiento, abre y cierra el formulario de detalle del ticket cincuenta veces, toma un segundo snapshot y compáralos: los formularios retenidos están enraizados por una suscripción estática a GlobalTicketBus.TicketChanged y por un temporizador de actualización que nunca se detuvo. Cancela la suscripción y detén ambos en un Dispose sobrescrito, limpia el origen de datos del BindingSource y vuelve a ejecutar el escenario de apertura/cierre para mostrar que el heap retenido vuelve a acercarse al snapshot A. Entregables: Traza de asignaciones que nombra el tipo con más asignaciones y la ruta de llamadas del escenario de búsqueda, antes y después; Comparación de los snapshots A/B que muestra el número de instancias retenidas del formulario de detalle antes de la corrección; Captura de la ruta a la raíz que identifica la suscripción al evento estático y el temporizador activo; Sobrescritura de Dispose que cancela la suscripción al evento estático, detiene y libera el temporizador y limpia el enlace de datos; Presupuesto de memoria por sesión y lista de comprobación de liberación, con el snapshot «después» que demuestra que la ruta de retención ha desaparecido.
Módulo 5: Controles de datos, cargas útiles del navegador y grandes superficies de interfaz
Módulo 5 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre las grandes superficies de interfaz, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
Grids, listas, árboles y repetidores a escala: modo virtual, paginación, proyección y carga diferida de nodos, y el uso de la evidencia de red del navegador junto a la de Visual Studio para dimensionar la carga útil de actualización. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoCincuenta mil filas sin cincuenta mil controles · 14 min
Cincuenta mil filas sin cincuenta mil controles: un recorrido guiado del Módulo 5, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Módulo cinco. Las cuadrículas y los árboles grandes pueden ralentizar una aplicación antes de que el usuario haga algo. Reduciremos los datos y controles cargados a la vez y luego mediremos el efecto tanto en el servidor como en el navegador.
Una red grande tiene costos en cuatro lugares. El servidor almacena los objetos y prepara la actualización. La red lo transporta y el navegador lo muestra. Medir por sí solo el rendimiento del servidor permitirá pasar por alto parte del problema.
Primero, proyecte cada registro en un objeto más pequeño que contenga los campos que necesita la pantalla. Luego use el modo virtual para evitar mantener cada fila en la memoria. Estos cambios resuelven diferentes partes del problema, así que aplique ambos.
Configure RowCount desde una consulta de recuento. Cuando CellValueNeeded solicite un valor, léalo en la proyección paginada. Evite una consulta de base de datos para cada celda y siga formateando sin este controlador.
Aplique el mismo principio a otros controles. Cargue árboles secundarios cuando su padre se expanda, virtualice listas largas, mantenga las plantillas repetidas simples y actualice solo las filas del panel que cambiaron.
Mientras el nodo del árbol está colapsado, mantenga un recuento y un elemento secundario como marcador de posición. El marcador de posición conserva el control de expansión. Cree los nodos secundarios reales solo cuando el usuario abra esa rama.
Compara las medidas del servidor. La cuadrícula contiene cuarenta objetos de fila en lugar de cincuenta mil. La memoria cae de 186 a nueve megabytes y el tiempo de procesamiento cae de 1.410 a 95 milisegundos. A continuación, verifique qué cambió en el navegador.
Ahora inspecciona el tráfico del navegador. La actualización de la red se reduce de 4,8 megabytes a 96 kilobytes. Seis actualizaciones más pequeñas sirven para el desplazamiento posterior. Informe tanto el número como el tamaño de las solicitudes para que las medidas muestren el costo completo.
Para el laboratorio cinco, proyecte y virtualice la red, luego cargue ramas de árboles según sea necesario. Utilice Visual Studio para medir el servidor y el panel de red para medir el tráfico del navegador. Su evidencia debe cubrir ambos.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 5 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Cuadrícula virtual y árbol con carga diferida · 45 min
Objetivo: Reduce las dos superficies más grandes de WisejPerfLab. El grid de tickets enlaza 50.000 entidades completas con propiedades de navegación: sustituye el enlace por una proyección TicketGridRow con solo las columnas visibles, establece VirtualMode y RowCount y sirve las celdas desde un controlador CellValueNeeded respaldado por un servicio de consultas paginadas. El árbol de clientes construye todos los nodos al arrancar: carga los hijos al expandir, usando un marcador de recuento para las ramas contraídas. Mide cada pantalla antes y después con CPU Usage y .NET Object Allocation en el servidor, y con el panel de red del navegador para el tamaño de la carga útil de actualización. Entregables: Proyección TicketGridRow enlazada en lugar de entidades completas, solo con las columnas mostradas; Grid en modo virtual con RowCount y un controlador CellValueNeeded servido desde un servicio de consultas paginadas; Árbol de clientes que carga los nodos hijos al expandir con un marcador de recuento para las ramas contraídas; Cifras de CPU y asignaciones antes/después para los escenarios de carga del grid y expansión del árbol; Evidencia de red del navegador que compara el tamaño de la carga útil de actualización antes y después, con la advertencia sobre la compresión.
Módulo 6: Base de datos, E/S de archivos, async y esperas externas
Módulo 6 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre la base de datos y async, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
La latencia que CPU Usage no puede ver: la herramienta Database para los tiempos de consulta y los patrones N+1, File I/O para el trabajo de importación y exportación, y .NET Async para las cadenas bloqueadas o secuenciales por accidente. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoCPU baja, pantalla lenta: haz profiling de la espera · 14 min
CPU baja, pantalla lenta: haz profiling de la espera: un recorrido guiado del Módulo 6, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Un procesador silencioso puede acompañar a una aplicación lenta. Utilice el seguimiento de actualización anterior para investigar la espera en lugar de intentar optimizar el cálculo que no explica el retraso.
Atribuya el tiempo faltante a las operaciones de la base de datos, el acceso a archivos y los subprocesos bloqueados. Estas esperas requieren sus propias mediciones porque las muestras del procesador describen principalmente el trabajo realizado durante la ejecución.
Inspeccione cómo la pantalla obtiene sus filas. Las búsquedas repetidas y el exceso de campos añaden trabajo evitable a la base de datos; proyectar los campos obligatorios juntos puede eliminar varios problemas a la vez.
Agregue el nombre del cliente a la consulta y seleccione solo los campos mostrados. Ordene y pagina los resultados, utilizando lecturas sin seguimiento cuando la pantalla no necesita seguimiento de cambios.
Espere operaciones de entrada y salida para que una solicitud en espera no ocupe un hilo innecesariamente. Esto mejora la disponibilidad de recursos; no hace que la base de datos o el disco subyacentes sean más rápidos.
Elimine el bloqueo del acceso a los resultados y transmita la exportación en lugar de emitir muchas escrituras pequeñas. Envíe el progreso a intervalos significativos para que los comentarios no se conviertan en otra fuente de gastos generales.
Compare los recuentos de consultas después del cambio. Pasar de doscientas una consultas a dos confirma esta corrección, aunque otro coste todavía impide que el escenario cumpla con su presupuesto.
Repita la exportación con sesiones simultáneas. Un bloqueo que parece inofensivo para un usuario puede agotar los hilos disponibles y retrasar pantallas no relacionadas cuando muchos usuarios lo realizan juntos.
Conecte cada consulta a su acción de interfaz, luego compare antes y después. Explique tanto el trabajo de la base de datos eliminada como cómo la exportación evita bloquear la ruta de clic.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 6 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Trazas de consultas y la exportación bloqueada · 45 min
Objetivo: Perfila los dos escenarios dominados por esperas en WisejPerfLab. Ejecuta la búsqueda de tickets con la herramienta Database y asocia cada consulta a la acción de interfaz: la carga del grid lanza una consulta de cliente por cada fila mostrada y la consulta de detalles trae grandes columnas de texto que nadie muestra. Sustituye ambas por una única consulta de proyección sin seguimiento que seleccione solo las columnas del grid y pagine el resultado. Después ejecuta la exportación CSV con File I/O y .NET Async, encuentra la llamada bloqueante .Result en el controlador del clic y las escrituras pequeñas repetidas, y traslada la generación a un flujo en segundo plano con Application.StartTask que escriba el archivo en streaming e informe del progreso de forma limitada en lugar de hacer push en cada paso. Entregables: Traza de Database que asocia las consultas a las acciones de interfaz, con el número de consultas N+1 antes de la corrección; Única consulta de proyección sin seguimiento con paginación que sustituye las consultas por fila y las que traen datos de más; Evidencia de File I/O y .NET Async para la exportación, que nombra la llamada bloqueante y el patrón de escritura; Exportación trasladada a una tarea en segundo plano que escribe la salida en streaming y hace push del progreso solo en los pasos significativos; Número de consultas, duración de las consultas y tiempo de reloj de la exportación antes/después, con los riesgos restantes.
Módulo 7: Escalado, comprobaciones de estado, balanceo de carga y ajuste final
Módulo 7 de Rendimiento y profiling — mide, perfila y ajusta aplicaciones Wisej.NET para que las sesiones sigan siendo rápidas a escala. Lee la guía de la lección y la guía del laboratorio / examen, mira el recorrido guiado sobre el escalado y los health checks, supera la evaluación de conocimientos y completa el laboratorio práctico en WisejPerfLab.
- LecturaGuía de la lección · 14 min
Convertir mediciones en un modelo de capacidad, umbrales de HealthCheck.json, afinidad de sesión y balanceo de carga compatible con WebSocket, contadores de producción y el informe final de rendimiento que justifica cada cambio. Qué significa esto para un desarrollador de Wisej.NET que diagnostica cuellos de botella en una aplicación en producción, y cómo leer este módulo.
- LecturaGuía del laboratorio / examen · 10 min
Qué construirás en el laboratorio práctico, el enfoque sugerido y los entregables requeridos.
- Lección en vídeoDe una traza local a un modelo de capacidad · 14 min
De una traza local a un modelo de capacidad: un recorrido guiado del Módulo 7, construido paso a paso en WisejPerfLab. Se reproduce aquí mismo, en el reproductor.
Transcripción de la narración
Traduzca los resultados de la elaboración de perfiles en límites operativos. Una aplicación más rápida aún necesita una capacidad de sesión defendible y un plan para desviar a los nuevos usuarios de un servidor completo.
Multiplique la memoria de sesión medida por el recuento de sesiones propuesto y compárelo con la memoria utilizable. Mantenga margen de maniobra porque las sesiones inactivas no describen cada asignación máxima.
Conserve la afinidad de sesiones en toda la implementación y permita actualizaciones de WebSocket a través de servidores proxy. Los controles con estado necesitan el servidor correcto y las actualizaciones en vivo necesitan una ruta de transporte ininterrumpida.
Establezca umbrales de salud a partir de la capacidad medida en lugar de conjeturas convenientes. La respuesta incorrecta y la guía de reintento le dan a la infraestructura una señal de cuándo la instancia debería dejar de recibir nuevas sesiones.
Monitorear la señal que corresponde a cada problema corregido. Las duraciones de los escenarios, el tamaño del montón administrado y las colas del grupo de subprocesos revelan regresiones diferentes y no deben tratarse como intercambiables.
Escriba un informe que conecte el escenario original con su causa, corrección y evidencia. Incluya riesgos y comprobaciones operativas para que un colega pueda verificar la mejora después de la implementación.
Observe lo que sucede cuando la instancia A alcanza su capacidad. El nuevo tráfico avanza hacia la instancia B mientras continúan las sesiones establecidas, separando el control de admisión de la interrupción de los usuarios existentes.
Compare cada escenario con su presupuesto original. Mantenga la exportación marcada como un riesgo porque un objetivo ausente y las pruebas de simultaneidad limitadas no pueden respaldar una afirmación aprobada.
Entregue el cálculo de capacidad, la configuración de estado, las notas de implementación y el informe reproducible juntos. Las operaciones necesitan tanto los límites elegidos como la evidencia que explique por qué esos límites son apropiados.
- LecturaEjercicio de programación con IA · 20 min
Construye el ejemplo OpsMonitor de este módulo con ChatGPT o Claude a partir de un prompt listo para usar que dirige al modelo a la especificación del módulo, y después revisa, ejecuta y amplía lo que te devuelva — incluso comparándolo con nuestra propia solución de referencia en GitHub.
- CuestionarioEvaluación de conocimientos — Módulo 7 · 10 min · Nota mínima 80%
- Laboratorio prácticoLaboratorio — Modelo de capacidad e informe del proyecto final · 45 min
Objetivo: Entrega el proyecto final de WisejPerfLab. Deriva un modelo de capacidad a partir de tus propias mediciones: memoria retenida por sesión inactiva, CPU por escenario habitual, concurrencia máxima esperada y el margen que reservas. Escribe un HealthCheck.json cuyos maxSessions, maxMemory y maxCPU salgan de esas cifras y explica cada umbral, devolviendo 503 con un retry-after para que el balanceador de carga dirija a los nuevos usuarios a otro sitio mientras las sesiones existentes siguen funcionando. Escribe las notas de despliegue para dos instancias detrás de un balanceador de carga con afinidad de sesión y soporte de WebSocket, y ensambla el informe final: escenarios, entorno, evidencia de línea base, causas raíz, cambios, evidencia posterior, riesgos restantes y los contadores de producción que mostrarán si vuelve una regresión. Entregables: Modelo de capacidad que deriva las sesiones por servidor de la memoria medida por sesión y la CPU por escenario; HealthCheck.json con maxSessions, maxMemory, maxCPU, código de retorno y retry-after, con cada umbral justificado; Notas de despliegue que cubren la afinidad de sesión, el soporte de WebSocket y el fallback a polling; Informe final de rendimiento con línea base, causa raíz, cambio y evidencia posterior para cada corrección de módulo; Plan de monitorización que nombra los contadores, umbrales y alertas que detectarían cada regresión.