Compartir vía

Preguntas más frecuentes sobre el rendimiento de aplicaciones para Web Apps de Azure

  • Artículo

Nota:

Es posible que algunas de las directrices siguientes solo funcione en App Services de Windows o de Linux. Por ejemplo, App Services de Linux se ejecuta en modo de 64 bits de manera predeterminada.

En este artículo se proporcionan las respuestas a las preguntas más frecuentes sobre los problemas relacionados con el rendimiento de las aplicaciones en la característica Web Apps de Azure App Service.

Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow. Puede publicar su problema en ellos o en @AzureSupport en Twitter. También puede enviar una solicitud de soporte técnico de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure, seleccione Obtener soporte técnico.

¿Por qué mi plan de App Service muestra el uso de CPU/memoria incluso cuando se detienen todas las aplicaciones web?

App de Azure Service requiere procesos continuos del sistema que controlan varias operaciones y características de la plataforma, como actualizaciones de seguridad, disponibilidad de la consola SCM, supervisión de aplicaciones, autenticación y muchas otras características vitales de la aplicación web.

Los procesos del sistema se ejecutarán en planes de App Service aunque no haya ninguna aplicación web en ejecución o si el plan de App Service no contiene aplicaciones web.

Los procesos de plataforma consumirán una cantidad mínima de recursos (como CPU, memoria y espacio en disco) y se deben tener en cuenta los mismos durante la configuración del desencadenador de planeamiento, supervisión y escalado automático de capacidad de un plan de App Service.

¿Por qué mi aplicación es lenta?

Varios factores podrían contribuir a la ralentización del rendimiento de la aplicación. Para obtener los pasos detallados de solución de problemas, consulte Solucionar los problemas de rendimiento reducido de aplicaciones web en Azure Web Apps.

¿Cómo puedo solucionar problemas en un escenario de consumo elevado de CPU?

En algunos escenarios de consumo elevado de CPU, es probable que la aplicación realmente requiera más recursos informáticos. En ese caso, considere la posibilidad de escalar a un mayor nivel de servicio para que la aplicación obtenga todos los recursos necesarios. En otras ocasiones, el consumo elevado de CPU podría deberse a un bucle incorrecto o una práctica de codificación. Obtener una visión general de lo que está desencadenando ese mayor consumo de CPU es un proceso de dos partes. En primer lugar, cree un volcado de proceso y, después, analice el volcado de memoria del proceso. Para más información, consulte la entrada de blog Capture and analyze a dump file for high CPU consumption for Web Apps (Captura y análisis de un archivo de volcado de memoria para un consumo elevado de CPU para Web Apps).

¿Cómo puedo solucionar problemas en un escenario de consumo elevado de memoria?

En algunos escenarios de consumo elevado de memoria, es probable que la aplicación realmente requiera más recursos informáticos. En ese caso, considere la posibilidad de escalar a un mayor nivel de servicio para que la aplicación obtenga todos los recursos necesarios. En otras ocasiones, un error del código podría producir una pérdida de memoria. Una práctica de codificación también podría aumentar el consumo de memoria. Obtener una visión general de lo que está desencadenando ese mayor consumo de memoria es un proceso de dos partes. En primer lugar, cree un volcado de proceso y, después, analice el volcado de memoria del proceso. El diagnóstico de bloqueos de la galería de extensión de sitios de Azure puede realizar de manera eficaz estos dos pasos. Para más información, consulte la entrada de blog How to capture and analyze dump for intermittent High Memory on Azure Web App (Captura y análisis de un archivo de volcado de memoria para un consumo elevado intermitente de memoria para Web Apps).

¿Cómo se puede automatizar App Service Web Apps mediante PowerShell?

Puede usar los cmdlets de PowerShell para administrar y mantener App Service Web Apps. En nuestra entrada de blog Automate web apps hosted in Azure App Service by using PowerShell (Automatización de aplicaciones web hospedadas en Azure App Service mediante PowerShell), se describe cómo usar los cmdlets de PowerShell basada en Azure Resource Manager para automatizar tareas comunes. La entrada de blog también incluye código de ejemplo para diversas tareas de administración de aplicaciones web. Para obtener descripciones y sintaxis de todos los cmdlets de App Service Web Apps, consulte Az.Websites.

¿Cómo se pueden ver los registros de eventos de mi aplicación web?

Para ver los registros de eventos de la aplicación web:

  1. Inicie sesión en su sitio web de Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
  2. En el menú, seleccione Consola de depuración>CMD.
  3. Seleccione la carpeta LogFiles.
  4. Para ver los registros de eventos, seleccione el icono de lápiz junto a eventlog.xml.
  5. Para descargar los registros, ejecute el cmdlet de PowerShell Save-AzureWebSiteLog -Name webappname.

¿Cómo se puede capturar un volcado de memoria de modo de usuario de la aplicación web?

Para capturar un volcado de memoria de modo de usuario de la aplicación web:

  1. Inicie sesión en su sitio web de Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
  2. Seleccione el menú Explorador de procesos.
  3. Haga clic con el botón derecho en el proceso w3wp.exe o en el proceso de trabajo web.
  4. Seleccione Download Memory Dump>Full Dump (Descargar volcado de memoria > Volcado de memoria completo).

¿Cómo se puede ver la información de nivel de proceso para mi aplicación web?

Tiene dos opciones para ver la información de nivel de proceso para la aplicación web:

  • En el Portal de Azure:
    1. Abra el explorador de procesos para la aplicación web.
    2. Para ver los detalles, seleccione el proceso w3wp.exe.
  • En la consola de Kudu:
    1. Inicie sesión en su sitio web de Kudu (https://*yourwebsitename*.scm.azurewebsites.net).
    2. Seleccione el menú Explorador de procesos.
    3. En el proceso w3wp.exe, seleccione Propiedades.

Cuando vaya a mi aplicación, veo "Error 403: esta aplicación web está detenida". Cómo resolver esto?

Este error pueden deberse a tres condiciones:

  • La aplicación web ha alcanzado un límite de facturación y se ha deshabilitado el sitio.
  • La aplicación web se detuvo en el portal.
  • La aplicación web ha alcanzado un límite de cuota de recursos que se puede aplicar a un plan de servicio de escala Gratis o Compartido.

Para ver cuál es la causa del error y resolver el problema, siga los pasos de Web Apps: "Error 403 – This web app is stopped" (Web Apps: "Error 403: esta aplicación web se ha detenido").

¿Dónde puedo obtener más información sobre cuotas y límites de los diversos planes de App Service?

Para más información sobre cuotas y límites, consulte Límites de App Service.

¿Cómo se puede reducir el tiempo de respuesta de la primera solicitud después de tiempo de inactividad?

De forma predeterminada, las aplicaciones web se descargan si están inactivas durante un período de tiempo establecido. Esto permite que el sistema conserve recursos. El inconveniente es que la respuesta a la primera solicitud después de descargar la aplicación web es más larga, para que la aplicación web pueda cargar y comenzar a atender a las respuestas. En los planes de servicio Básico y Estándar, puede activar el valor Siempre activado para que la aplicación web se mantenga cargada en todo momento. Esto elimina mayores tiempos de carga después de la inactividad de la aplicación. Para cambiar la configuración de Siempre activado:

  1. En Azure Portal, vaya a la aplicación web.
  2. Seleccione Configuración.
  3. Seleccione Configuración general.
  4. Para Siempre activado, seleccione Activado.

¿Cómo se activa el seguimiento de solicitudes con error?

Para activar el seguimiento de solicitudes con error, siga estos pasos:

  1. En Azure Portal, vaya a la aplicación web.

  2. Seleccione Toda la configuración>Registros de diagnóstico.

  3. En Seguimiento de solicitudes con error, seleccione Activado.

  4. Haga clic en Guardar.

  5. En la hoja de aplicación web, seleccione Herramientas.

  6. Seleccione Visual Studio Online.

  7. Si la configuración no está activada, seleccione Activado.

  8. Seleccione Ir.

  9. Seleccione Web.config.

  10. En system.webServer, agregue la siguiente configuración (para capturar una dirección URL específica):

    <system.webServer>
<tracing> <traceFailedRequests>
<remove path="*api*" />
<add path="*api*">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

  11. Para solucionar problemas de rendimiento lento, agregue esta configuración (si la solicitud de captura está tardando más de 30 segundos):

    <system.webServer>
<tracing> <traceFailedRequests>
<remove path="*" />
<add path="*">
<traceAreas> <add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>

  12. Para descargar los seguimientos de solicitudes con error, en el portal, vaya al sitio web.

  13. Seleccione Herramientas>Kudu>Ir.

  14. En el menú, seleccione Consola de depuración>CMD.

  15. Seleccione la carpeta LogFiles y, después, seleccione la carpeta con un nombre que comienza por W3SVC.

  16. Para ver el archivo XML, seleccione el icono de lápiz.

Veo el mensaje "Proceso de trabajo solicitado reciclaje debido al límite de "Porcentaje de memoria". Cómo solucionar este problema?

La cantidad máxima de memoria disponible para un proceso de 32 bits (incluso en un sistema operativo de 64 bits) es de 2 GB. De forma predeterminada, el proceso de trabajo está establecido en 32 bits en App Service (por compatibilidad con aplicaciones web heredadas).

Considere la posibilidad de cambiar a procesos de 64 bits, por lo que podrá aprovechar la memoria adicional disponible en el rol de trabajo web. Esta acción desencadena un reinicio de la aplicación web, por lo que debe planificarlo debidamente.

Tenga en cuenta que un entorno de 64 bits requiere un plan de servicio Básico o Estándar. Los planes Gratis y Compartido siempre se ejecutan en un entorno de 32 bits.

Para más información, consulte Configuración de aplicaciones web en Azure App Service.

¿Por qué se agota el tiempo de espera de la solicitud después de 230 segundos?

Azure Load Balancer tiene un valor de tiempo de expiración de inactividad predeterminado de cuatro minutos. Por lo general, esta configuración suele ser un límite de tiempo de respuesta razonable para una solicitud web. Por lo tanto, App Service devuelve un tiempo de espera al cliente si la aplicación no devuelve una respuesta en aproximadamente 240 segundos (230 segundos en la aplicación de Windows, 240 segundos en la aplicación Linux).　Si la aplicación web requiere un procesamiento en segundo plano, se recomienda el uso de Azure WebJobs. La aplicación web de Azure puede llamar a WebJobs y se recibirá una notificación cuando haya finalizado el procesamiento en segundo plano. Puede elegir entre varios métodos para usar WebJobs, incluidos las colas y los desencadenadores.

WebJobs está pensado para el procesamiento en segundo plano. Puede realizar tanto procesamiento en segundo plano como desee en un WebJob. Para más información, consulte Ejecutar tareas en segundo plano con WebJobs.

Las aplicaciones de ASP.NET Core hospedadas en App Service a veces dejan de responder. ¿Cómo se corrige este problema?

Un problema conocido con una versión Kestrel anterior podía provocar que una aplicación de ASP.NET Core 1.0 hospedada en App Service de vez en cuando dejase de responder. También podía ver el mensaje: "La aplicación CGI especificada encontró un error y el servidor terminó el proceso".

Este problema está corregido Kestrel versión 1.0.2. Esta versión se incluye en la actualización de ASP.NET Core 1.0.3. Para resolver este problema, asegúrese de que actualiza las dependencias de la aplicación para usar Kestrel versión 1.0.2. Como alternativa, puede usar una de las dos soluciones alternativas que se describen en la entrada de blog ASP.NET Core 1.0 slow perf issues in App Service web apps (Problemas de rendimiento lento de ASP.NET Core 1.0 en aplicaciones web de App Service).

No se encuentran mis archivos de registro en la estructura de archivos de la aplicación web. ¿Cómo se pueden encontrar?

Si utiliza la característica de caché local de App Service, la estructura de carpetas de las carpetas de archivos de registro y datos para la instancia de App Service se verá afectada. Cuando se utiliza la memoria caché local, se crean las subcarpetas en las carpetas de datos y de archivos de registro del almacenamiento. Las subcarpetas usan el patrón de nomenclatura "identificador único" + marca de tiempo. Cada subcarpeta se corresponde con una instancia de máquina virtual en donde se ejecuta la aplicación web o se ha ejecutado.

Para determinar si usa caché local, compruebe la pestaña Configuración de la aplicación de App Service. Si se usa caché local, la configuración WEBSITE_LOCAL_CACHE_OPTION de la aplicación se establece en Always.

Si no usa la caché local y experimenta este problema, envíe una solicitud de soporte técnico.

Veo el mensaje "Se intentó acceder a un socket de una manera prohibida por sus permisos de acceso". Cómo resolver este error?

Este error suele producirse si se agotan las conexiones TCP salientes en la instancia de máquina virtual. En App Service, los límites se aplican para el número máximo de conexiones salientes que puede realizar cada instancia de máquina virtual. Para más información, consulte la sección Cross-VM numerical limits (Límites numéricos entre máquinas virtuales).

Este error también puede producirse si intenta tener acceso a una dirección local desde la aplicación. Para más información, consulte la sección Local address requests (Peticiones de direcciones locales).

Para más información acerca de las conexiones salientes en la aplicación web, consulte la entrada de blog sobre conexiones salientes a sitios web de Azure.

¿Cómo usar Visual Studio para depurar de forma remota la aplicación web de App Service?

Para ver un tutorial detallado que muestra cómo depurar la aplicación web con Visual Studio, consulte la entrada de blog Remote debug your App Service web app (Depuración de forma remota de la aplicación web de App Service).

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.