Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los escenarios y las actividades se pueden retrasar inesperadamente. Por ejemplo, abrir una pestaña dentro de Microsoft Edge a veces puede tardar más de lo esperado.
Una actividad se define como una serie de operaciones, algunas secuenciales y algunas paralelas, que fluyen de un evento de inicio a un evento final. Cualquier par de eventos de inicio y finalización de un seguimiento se puede ver como una actividad. La ruta de acceso más larga a través de esta serie de operaciones se conoce como ruta de acceso crítica. Reducir la duración de cualquier operación en la ruta crítica reduce directamente la duración de la actividad general.
Se recomienda identificar el proceso y el subproceso que completó la actividad y trabajar hacia atrás desde el momento en que se completó la actividad. Empiece por analizar el subproceso que completó la actividad para determinar cómo pasó la mayor parte de su tiempo y en qué estado: en ejecución, listo o en espera.
Los tiempos de ejecución significativos indican que el uso directo de la CPU podría contribuir a la duración de la ruta de acceso crítica. El tiempo invertido en el estado listo indica que otros subprocesos contribuyen a la duración de la ruta crítica evitando que se ejecute un subproceso en la ruta crítica. Tiempo dedicado a la espera de puntos de E/S, temporizadores u otros subprocesos y procesos en la ruta crítica para la que el subproceso actual estaba esperando.
Cada subproceso que prepara el subproceso actual es probablemente otro vínculo en la ruta crítica y también se puede analizar hasta que se tenga en cuenta la duración de la ruta crítica.
Toda la información necesaria se registra en el gráfico uso de CPU (preciso) y la tabla en WPA. Los eventos de uso de CPU registrados por el distribuidor están asociados a modificadores de contexto. Esta tabla se centra en NewThread , que es el subproceso en el que se cambió y cada fila representa un modificador de contexto. Los datos se recopilan para la siguiente secuencia de eventos:
NewThread se desactiva debido a una llamada de función de bloqueo.
NewThread está listo para ejecutarse mediante el subproceso listo.
NewThread se cambia y, por tanto, se cambia un subproceso antiguo.
NewThread se vuelve a desactivar.
Estas son las columnas interesantes de la tabla Uso de CPU (precisa).
| Columna | Detalles |
|---|---|
| % de uso de CPU | Uso de CPU del nuevo subproceso después de cambiarlo. Este valor se expresa como un porcentaje del tiempo total de CPU durante el período de tiempo visible actualmente. |
| Recuento | Número de modificadores de contexto representados por la fila. Esto siempre es 1 para filas individuales. |
| Uso de CPU (ms) | Uso de CPU del nuevo subproceso después del modificador de contexto. |
| NewProcess | Proceso del nuevo subproceso. |
| NewThreadId | Identificador de subproceso del nuevo subproceso. |
| NewThreadStack | Pila del nuevo subproceso cuando se cambia. Normalmente indica lo que el subproceso se bloqueó o estaba esperando. |
| Listos | El tiempo que el subproceso pasó en la cola Listo (debido a la interrupción previa o a la inanición de la CPU). |
| ReadyingThreadId | Identificador de subproceso del subproceso listo. |
| ReadyingProcess | Proceso que posee el subproceso de preparación. |
| ReadyThreadStack | Pila del subproceso de preparación. |
| ReadyTime (s) | Hora en la que se ha fácil el nuevo subproceso. |
| SwitchInTime(s) | Hora en la que se cambió el nuevo subproceso. |
| Esperas (s) | Cantidad de tiempo que un subproceso ha esperado en un recurso lógico o físico. La espera finaliza cuando ReadyingThreadId señala a NewThreadId. |
Paso 1: Capturar y abrir un seguimiento para un problema de retraso de la interfaz de usuario
Este ejercicio se centrará en un proceso ficticio con una interfaz de usuario que no responde. El proceso es una sencilla aplicación de Windows Forms con un botón y un cuadro de texto. Cuando se hace clic en el botón, la interfaz de usuario deja de responder durante 20 segundos hasta que se actualiza el cuadro de texto. Analizará la ruta crítica de esta operación.
Descargue UIDelay.exe desde aquí.
Inicie UIDelay.exe.
Abra WPR desde el menú Inicio .
Modifique la configuración de seguimiento.
Seleccione Evaluación de prioridades de primer nivel y uso de CPU.
Seleccione General como escenario de rendimiento.
Seleccione Detallado como nivel de detalle.
Haga clic en Inicio.
En UIDelay.exe, haga clic en el botón Hacer clic .
- Espere hasta que el cuadro de texto muestre "Listo!"
En WPR, guarde el seguimiento y ábralo con WPA.
Abra el menú Seguimiento y seleccione Configurar ruta de acceso de símbolos.
- Especifique la ruta de acceso de la memoria caché de símbolos. Para obtener más información sobre los símbolos, vea la página Compatibilidad con símbolos en MSDN.
Abra el menú Seguimiento y seleccione Cargar símbolos.
Paso 2: Identificar el subproceso de interfaz de usuario retrasado
Antes de realizar el análisis de rutas de acceso críticas, primero debe identificar los eventos de inicio y detención de la actividad.
Busque el gráfico Retrasos de la interfaz de usuario en el nodo Actividad del sistema del Probador de Graph.
Arrastre y coloque el gráfico Retrasos de la interfaz de usuario en la pestaña de análisis.
Busque el proceso deUIDelay.exe .
Su duración debe ser de aproximadamente 20 segundos. Esto indica que hubo un retraso de 20 segundos en el subproceso de interfaz de usuario deUIDelay.exe.
El identificador del subproceso de interfaz de usuario se muestra en la columna Identificador de subproceso . En este ejemplo, es 24174. Este valor será diferente en el seguimiento que ha capturado en la máquina. Asegúrese de anotar el identificador del subproceso.
Seleccione todo el intervalo de tiempoUIDelay.exe , haga clic con el botón derecho y haga zoom.
Siempre debe acercar las regiones que intenta analizar. Reduce la cantidad de ruido introducido por actividades no relacionadas.
Paso 3: Análisis de la ruta crítica de retraso de la interfaz de usuario
Ahora que tiene un punto de partida de análisis con el identificador de subproceso y las marcas de tiempo, puede empezar a profundizar en la ruta crítica de la actividad para comprender la secuencia de eventos que conducen a un retraso de 20 segundos en el subproceso de la interfaz de usuario.
NewThreadId para este paso es el subproceso que identificó en el paso 2 (subproceso 24174 en UIDelay.exe proceso).
Agregue el gráfico Uso de CPU (precisa) a la pestaña análisis y aplique el valor preestablecido Uso por proceso y subproceso .
Haga clic con el botón derecho en los encabezados de columna y haga visibles las columnas NewThreadStack, ReadyThreadStack y Uso de CPU (ms).
Quite las columnas Ready (us) [Max] y Waits (us) [Max]. La ventanilla debería tener ahora un aspecto similar al siguiente.
Busque y expanda el proceso deUIDelay.exe en la columna NewProcess y ordene por Esperas (us) [Sum] haciendo clic en el encabezado de columna.
Busque NewThreadId en el proceso deUIDelay.exe y analice su tiempo invertido en el estado En ejecución, Listo o En espera.
En el ejemplo siguiente, puede encontrar lo siguiente:
El subproceso consume 10,025 segundos de tiempo de CPU.
El subproceso espera 5,159 segundos.
El subproceso está en estado listo para una cantidad de tiempo insignificante (10 ms).
Nota Puede analizar los 10 segundos de actividad de CPU mediante la misma metodología descrita en el ejercicio 2, paso 4 mediante el gráfico Uso de CPU (muestreado) y examinando el proceso deUIDelay.exe .
Para descubrir lo que el NewThreadId estaba esperando, expanda el grupo NewThreadId para mostrar NewThreadStack.
Expanda [Raíz] e identifique las llamadas de función que conducen a esperas.
En este ejemplo, UIDelay.exe identificador de subproceso 24174 está esperando llamadas de función de bloqueo subyacentes durante 5,073 segundos cuando se desencadena la función de clic del botón:
5.021 segundos se deben a las operaciones debajo de la función ExecuteWMICall .
35 ms se deben a operaciones debajo de la función PingServer .
Paso 3.1: Examine la ruta de acceso de código ExecuteWMICall
Si expande aún más la pila de llamadas en ExecuteWMICall, verá que el subproceso de la interfaz de usuario está en suspensión durante 5 segundos llamando explícitamente a Thread.Sleep.
Este tipo de comportamiento debe evitarse a todo costo, ya que afecta directamente a la capacidad de respuesta. Si el código necesita esperar información, debe hacerlo de forma asincrónica en un subproceso independiente y usar un método controlado por eventos.
Paso 3.2: Examinar el código de PingServer
Si expande aún más la pila de llamadas en PingServer, encontrará que el subproceso de interfaz de usuario tiene dependencias de E/S, ya que envía comandos ping a través de la red.
Aunque el retraso es muy pequeño (35 ms), debe evitarse en un subproceso de interfaz de usuario. Tenga en cuenta que la persona promedio observará cualquier retraso de la interfaz de usuario superior a 100 ms. Esta operación podría aumentar el tiempo total de actividad transcurrido por encima de 100 ms, lo que da lugar a que los usuarios tengan una mala percepción de capacidad de respuesta.
Esas operaciones deben producirse de forma asincrónica en un subproceso independiente y no bloquear la interfaz de usuario.