Se usó la API de Cloud Translation para traducir esta página.

504 Gateway Timeout

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Síntoma

La aplicación cliente recibe un código de estado HTTP de 504 con el mensaje Gateway Timeout como respuesta para las llamadas a la API

El error 504 Gateway Timeout del código de estado HTTP indica que el cliente no recibieron una respuesta oportuna de la puerta de enlace perimetral o del servidor de backend durante la ejecución de una API

Mensajes de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 504 Gateway Timeout

En algunos casos, también se puede observar el siguiente mensaje de error:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

¿Qué causa los tiempos de espera de la puerta de enlace?

La ruta típica para una solicitud a la API a través de la plataforma perimetral será Client -> Router -> Procesador de mensajes -> Backend Server, como se muestra en la siguiente figura:

La aplicación cliente, los routers y los procesadores de mensajes de la plataforma perimetral se configuran con valores de tiempo de espera adecuados. La plataforma perimetral espera que se envíe una respuesta en un período determinado de tiempo para cada solicitud a la API según los valores de tiempo de espera. Si no recibes la respuesta en un plazo durante el período especificado, se muestra 504 Gateway Timeout Error.

En la siguiente tabla, se proporcionan más detalles sobre cuándo pueden ocurrir tiempos de espera en Edge:

Tiempo de espera de caso	Detalles
Se produce el tiempo de espera en Message Processor	El servidor de backend no responde al Message Processor en un tiempo de espera especificado. en el procesador de mensajes. Se agota el tiempo de espera del procesador de mensajes y envía el estado de respuesta como `504 Gateway Timeout` al router.
Se agota el tiempo de espera en el router	El procesador de mensajes no responde al router dentro del tiempo de espera especificado. en el router. Se agota el tiempo de espera del router y envía el estado de respuesta como `504 Gateway Timeout` a la aplicación cliente.
Se produce el tiempo de espera en la aplicación cliente	El router no responde a la aplicación cliente dentro del tiempo de espera especificado. en el router. Se agota el tiempo de espera de la aplicación cliente y finaliza el estado de respuesta como `504 Gateway Timeout` para el usuario final.

Causas posibles

En Edge, las causas típicas del error 504 Gateway Timeout son las siguientes:

Causa	Detalles	Pasos dados para
Servidor de backend lento	El servidor de backend que procesa la solicitud a la API es demasiado lento debido a una carga o un rendimiento deficiente.	Usuarios de nubes públicas y privadas
Procesamiento lento de solicitudes a la API por parte de Edge	Edge tarda mucho tiempo en procesar la solicitud a la API debido a la carga alta o mala rendimiento.

Lenta servidor de backend

Si el servidor de backend es muy lento o tarda mucho tiempo en procesar la solicitud a la API, entonces recibirás un error 504 Gateway Timeout. Como se explicó en la sección anterior, el tiempo de espera puede se producen en una de las siguientes situaciones:

Message Processor agota el tiempo de espera antes de que el servidor de backend responda.
Se agota el tiempo de espera del router antes de que el servidor de backend o procesador de mensajes responda.
Se agota el tiempo de espera de la aplicación cliente antes de que el router, procesador de mensajes o servidor de backend responda.

En las siguientes secciones, se describe cómo diagnosticar y resolver el problema en cada uno de estos reales.

Situación 1: Se agota el tiempo de espera del procesador de mensajes antes de que el servidor de backend responda

Diagnóstico

Puedes usar los siguientes procedimientos para diagnosticar si se produjo el error 504 Gateway Timeout debido al servidor de backend lento.

Procedimiento 1: Usa Trace

Si el problema persiste (504 todavía se producen errores), sigue los pasos que se indican a continuación. pasos:

Hacer un seguimiento de la API afectada en la IU de Edge. Espera a que se produzca el error o si Luego, realiza algunas llamadas a la API y reproduce el error 504 Gateway Timeout.
Una vez que se produjo el error, examina la solicitud específica que muestra el código de respuesta como 504
Comprueba el tiempo transcurrido en cada fase y toma nota de la fase en la que se reduce la mayor cantidad del tiempo. de los recursos que gastas.
Si observas el error con el tiempo transcurrido más largo inmediatamente después de uno de siguientes fases, indica que el servidor de backend es lento o tarda mucho tiempo en procesar la solicitud:
- Se envió la solicitud al servidor de destino
- Política ServiceCallout

A continuación, se proporciona un seguimiento de muestra en el que se indica que el servidor de backend ni siquiera respondió después de 55 segundos, lo que genera un error 504 Gateway Timeout:

En el seguimiento anterior, Message Processor agota el tiempo de espera después de 55,002 ms como lo hace el servidor de backend no responden.

Procedimiento 2: Usa los registros de Message Processor

Cómo consultar el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Si encuentras errores Gateway Timeout y onTimeoutRead para la solicitud específica del proxy de API. en un momento determinado, significa que se agotó el tiempo de espera del Message Processor.

Ejemplo de registro del procesador de mensajes en el que se muestra el error de tiempo de espera de la puerta de enlace

2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

En el registro de Message Processor anterior, observas que el servidor backend denotado con la IP dirección XX.XX.XX.XX no respondió, incluso después de 55 segundos (lastIO=55,000ms). Como resultado, se agotó el tiempo de espera de Message Processor y se envió un error 504 Gateway Timeout.

Verifica lo siguiente: ¿Cómo se controla el tiempo de espera en Message Processor?

Cómo se controla el tiempo de espera en Message Processor Los procesadores de mensajes suelen ser se establece con un valor de tiempo de espera predeterminado de 55 segundos) a través de la propiedad. HTTPTransport.io.timeout.millis Este valor de tiempo de espera es se aplicará a todos los proxies de API que pertenezcan a una organización que cumpla con esta Message Processor.
- Si el servidor de backend no responde en 55 segundos, el mensaje Se agota el tiempo de espera del procesador y se envía 504 Gateway Timeout error al cliente.
El valor de tiempo de espera especificado en Message Processor puede ser anulado por la propiedad io.timeout.millis especificadas dentro del proxy de API. Este valor de tiempo de espera se aplica a una API específica Proxy en el que se especifica la propiedad antes mencionada. Por ejemplo, si el io.timeout.millis se configura en 10 segundos en el proxy de API; luego, se usará el valor de tiempo de espera de 10 segundos para este proxy de API específico.
- Si el servidor de backend no responde en 10 segundos a la respuesta proxy de API, se agota el tiempo de espera de Message Processor y envía 504 Gateway Timeout error al cliente.

Solución

Comprueba por qué el servidor de backend tarda más de 55 segundos y observa si se puede se corrigen/optimizan para responder más rápido.
Si no es posible corregir u optimizar el servidor de backend o si se sabe que el servidor el servidor tarda más que el tiempo de espera configurado y, luego, Aumenta el valor de tiempo de espera del router y del procesador de mensajes a un valor adecuado.

Situación No 2: Se agota el tiempo de espera del router antes de que el procesador de mensajes o el servidor de backend responda.

Es posible que recibas errores 504 Gateway Timeout si se agota el tiempo de espera del router antes de que aparezca el mensaje el procesador/servidor de backend responde. Esto puede suceder en una de las siguientes circunstancias:

El valor de tiempo de espera establecido en el router es menor que el valor de tiempo de espera establecido en el mensaje. Procesador. Por ejemplo, supongamos que el tiempo de espera del router es de 50 segundos, mientras que el mensaje El procesador dura 55 segundos.

Tiempo de espera en el router	Tiempo de espera en Message Processor
50 segundos	55 segundos

El valor de tiempo de espera en Message Processor se anula con un valor de tiempo de espera más alto usando la propiedad io.timeout.millis establecida en la configuración del extremo de destino del proxy de API:

Por ejemplo, si se configuran los siguientes valores de tiempo de espera:

Tiempo de espera en el router	Tiempo de espera en Message Processor	Tiempo de espera en el proxy de API
57 segundos	55 segundos	120 segundos

Sin embargo, io.timeout.millis está configurado en 120 segundos en el proxy de API:

<HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

Luego, Message Processor no agota el tiempo de espera después de 55 segundos aunque haya transcurrido (55 segundos) es inferior al valor de tiempo de espera del router (57 segundos). Esto se debe a que el valor de tiempo de espera de 55 segundos en Message Processor se anula con el valor de 120 segundos que se configura en el proxy de API. Entonces, el valor de tiempo de espera del Message Processor para este proxy de API específico serán de 120 segundos.

Dado que el router tiene un valor de tiempo de espera más bajo (57 segundos) en comparación con los 120 segundos configurados en el proxy de API, se agotará el tiempo de espera del router si el servidor de backend no responde después de 57. segundos.

Diagnóstico

Verifica el registro de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Si se agota el tiempo de espera del router antes que el Message Processor, verás el estado 504. en los registros de acceso de NGINX para la solicitud a la API específica y el message id de Message Processor se configurará como -. Esto se debe a que el router no recibió ninguna respuesta del Message Processor dentro del tiempo de espera establecido en el router.

Ejemplo de una entrada de registro de NGINX que muestra 504 debido a que se agotó el tiempo de espera del router
En el ejemplo anterior, observa el estado de 504 en NGINX, el ID del mensaje de la El procesador es - y el tiempo total transcurrido es 57.001 segundos. Esto se debe a que se agotó el tiempo de espera del router después de 57.001 segundos y no obtuvimos ninguna respuesta del Message Processor.

En este caso, verás Broken Pipe excepciones en la sección Mensaje Registros del procesador (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Se muestra este error porque, una vez que se agota el tiempo de espera del router, se cierra la conexión con el Message Processor. Cuando el procesador de mensajes completa su procesamiento, intenta escribir el respuesta al router. Como la conexión al router ya está cerrada, obtendrás el Broken Pipe exception en Message Processor

Se espera que esta excepción se vea en las circunstancias explicadas anteriormente. Entonces, La causa del error 504 Gateway Timeout sigue siendo el servidor de backend que tarda más tiempo en responder. y necesitas resolver ese problema.

Solución

Si es un servidor backend personalizado,

Verifica por qué el servidor de backend tarda mucho tiempo en responder y observa si es posible se corrigen/optimizan para responder más rápido.

Si no es posible corregir u optimizar el servidor de backend o es un hecho conocido que el el servidor de backend tarda mucho tiempo. Luego, aumenta el valor del tiempo de espera en Router y procesador de mensajes.

Idea: Configure el valor de tiempo de espera en los diferentes componentes de las siguientes secciones: pedido:

Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el mensaje Procesador > Tiempo de espera en el proxy de API

Si es un servidor de backend de Node.js, haz lo siguiente:
1. Comprueba si el código NodeJS hace llamadas a algún otro servidor de backend y si tarda mucho tiempo para devolver una respuesta. Comprueba por qué los servidores backend tardan más tiempo solucionar el problema según corresponda.
2. Verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
  1. Si algún Message Processor tiene un uso elevado de CPU, genera tres conversación dumps cada 30 segundos con el siguiente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Si algún Message Processor tiene un uso elevado de memoria, genera un montón dump con el siguiente comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Usa el siguiente comando para reiniciar el Message Processor. Debería reducir la CPU y la memoria:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Supervisa las llamadas a la API para confirmar si el problema persiste.
  5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona la volcados de subprocesos, volcado de montón y registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudar investigar la causa del alto uso de CPU/memoria.

Verifica lo siguiente: Cómo se controla el tiempo de espera de los servidores de backend de NodeJS en Message Procesador

El servidor de backend NodeJS se ejecuta dentro del proceso JVM de Message Processor. El el valor de tiempo de espera para los servidores de backend de Node.js se controla a través de la propiedad http.request.timeout.seconds en el archivo nodejs.properties. Esta se establece en 0 de forma predeterminada, es decir, el tiempo de espera se inhabilita Proxies de API que pertenecen a una organización que entrega este Message Processor. Entonces, incluso si un servidor backend NodeJS lleva mucho tiempo, el Message Processor no agota el tiempo de espera.
Sin embargo, si el servidor de backend NodeJS tarda mucho y si el tiempo que tarda la API la solicitud es > 57 segundos, el router agotará el tiempo de espera y enviará 504 Gateway Timeout error al cliente.

Situación 3: Se agota el tiempo de espera de la aplicación cliente antes del router, el procesador de mensajes o el servidor de backend responde

Es posible que recibas errores 504 Gateway Timeout si se agota el tiempo de espera de la aplicación cliente antes de la el servidor de backend. Esta situación puede ocurrir en los siguientes casos:

El valor de tiempo de espera establecido en la aplicación cliente es menor que el valor de tiempo de espera establecido en la Router y procesador de mensajes:

Por ejemplo, si se configuran los siguientes valores de tiempo de espera:

Tiempo de espera en el cliente	Tiempo de espera en el router	Tiempo de espera en Message Processor
50 segundos	57 segundos	55 segundos

En este caso, el tiempo total disponible para obtener una respuesta a una solicitud a la API a través de Edge es menor o igual que 50 segundos. Esto incluye el tiempo necesario para realizar una solicitud a la API; la solicitud se que procesa Edge (enrutador, procesador de mensajes) y que la solicitud se envía al servidor de backend (si corresponde), el backend procesa la solicitud y envía la respuesta, el procesamiento perimetral respuesta y, por último, la envía de vuelta al cliente.

Si el router no responde al cliente en 50 segundos, el cliente el tiempo de espera y cierra la conexión con el router. El cliente obtendrá el código de respuesta de 504

Esto hará que NGINX establezca un código de estado de 499 para indicar que el cliente cerró el conexión.

Diagnóstico

Si se agota el tiempo de espera de la aplicación cliente antes de recibir una respuesta del router, cerrar la conexión con el router. En este caso, verás un código de estado de 499 en los registros de acceso de NGINX para la solicitud específica a la API.
Ejemplo de una entrada de registro NGINX que muestra el código de estado 499
En el ejemplo anterior, observa que el estado de 499 en NGINX y el tiempo total transcurrido es 50.001 segundos. Esto indica que se agotó el tiempo de espera del cliente después de 50.001 segundos.

En este caso, verás Broken Pipe excepciones en el mensaje Registros del procesador (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Una vez que se agota el tiempo de espera del router, se cierra la conexión con el Message Processor. Cuando El procesador de mensajes completa su procesamiento y, luego, intenta escribir la respuesta en el router. Como la conexión al router ya está cerrada, obtienes el Broken Pipe exception en el Message Processor.
Se espera esta excepción en las circunstancias que se explicaron anteriormente. Entonces, la causa real el error 504 Gateway Timeout sigue siendo que el servidor de backend tarda mucho tiempo en responder y que necesitas para abordar ese problema.

Solución

Si es tu servidor de backend personalizado, haz lo siguiente:

Verifica el servidor de backend para determinar por qué tarda más de 57 segundos y observa si Se puede optimizar o corregir para que responda más rápido.

Si no es posible corregir u optimizar el servidor backend o si sabe que el el servidor de backend demorará mucho tiempo, luego aumenta el valor del tiempo de espera en y el procesador de mensajes.

Idea: Configure el valor de tiempo de espera en los diferentes componentes de las siguientes secciones: pedido:

Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el mensaje Procesador > Tiempo de espera en el proxy de API

Si es un backend de Node.js, haz lo siguiente:
1. Verifica si el código NodeJS hace llamadas a algún otro servidor de backend y si eso es correcto. tardando mucho tiempo en regresar. Verifica por qué esos servidores de backend tardan más tiempo.
2. Verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
  1. Si un Message Processor tiene un uso elevado de CPU, genera tres conversación dumps cada 30 segundos con el siguiente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Si un Message Processor tiene un uso elevado de memoria, genera un volcado de montón con el siguiente comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Usa el siguiente comando para reiniciar el Message Processor. Esto debería reducir CPU y memoria:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Supervisa las llamadas a la API para confirmar si el problema persiste.
  5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona la volcados de subprocesos, volcado de montón y registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudarlos investigar la causa del alto uso de CPU/memoria.

Aumentar el valor del tiempo de espera en Router y procesador de mensajes

Elige cuidadosamente los valores de tiempo de espera que se configurarán en el router y el procesador de mensajes según según tus requisitos. No configures valores de tiempo de espera arbitrariamente grandes. Si necesitas ayuda, comunícate con Asistencia de Apigee Edge.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

Crea el archivo /opt/apigee/customer/application/router.properties en la máquina virtual, si aún no existe.
Agrega la siguiente línea a este archivo:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
```
Por ejemplo, si deseas establecer el valor del tiempo de espera de 120 segundos, configúralo como sigue:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
```
Asegúrate de que este archivo sea propiedad de Apigee:

Reinicia el router de la siguiente forma:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Si tienes más de un router, repite los pasos anteriores en todos ellos.

Message Processor

Crear archivo /opt/apigee/customer/application/message-processor.properties en en la máquina del procesador de mensajes, si aún no existe.
Agrega la siguiente línea a este archivo:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Por ejemplo, si deseas establecer el valor del tiempo de espera de 120 segundos, configúralo como sigue:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Asegúrate de que este archivo sea propiedad de Apigee:

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

Reinicia el procesador de mensajes:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Si tienes más de un Message Processor, repite los pasos anteriores en todos los mensajes Procesadores.

Idea: Configure el valor de tiempo de espera en los diferentes componentes en el siguiente orden:

Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en Message Processor > Tiempo de espera en el proxy de API

Procesamiento lento de solicitudes a la API por parte de Edge

Si Edge es muy lento o tarda mucho en procesar la solicitud a la API, obtendrás un mensaje 504 Gateway Timeout error.

Diagnóstico

Hacer un seguimiento de la API afectada en la IU de Edge.
Espera a que se produzca el error o, si recibes la llamada a la API, y realiza algunas llamadas a la API. y reproduce el error 504 Gateway Timeout.
Ten en cuenta que, en este caso, es posible que veas una respuesta exitosa en Trace.
1. Se agota el tiempo de espera del router o cliente, ya que el procesador de mensajes no responde dentro del tiempo de espera especificado en el router o cliente (el que tenga el período de tiempo de espera más bajo). Sin embargo, Message Processor continúa procesando la solicitud y puede completar con éxito.
2. Además, el valor HTTPTransport.io.timeout.millis establecido en el Message Processor se activa solo si este se comunica con un servidor HTTP/HTTPS servidor de backend. En otras palabras, este tiempo de espera no se activará cuando alguna política que la política ServicePrompt) en el proxy de API está tardando mucho tiempo.
Una vez ocurrido el error, examina la solicitud específica que tenga la tiempo transcurrido
Comprueba el tiempo transcurrido en cada fase y toma nota de la fase en la que se alcanza la mayor cantidad de tiempo. de los recursos que gastas.
Si observas el tiempo transcurrido más largo en cualquiera de las políticas que no sean la del Servicio La política de texto destacado indica que Edge está tardando mucho tiempo en procesar para cada solicitud.
Este es un ejemplo de seguimiento de la IU en el que se muestra un tiempo transcurrido muy alto en la política de JavaScript:
En el ejemplo anterior, observas que la política de JavaScript tarda una cantidad anormalmente larga de 245 segundos aproximadamente.

Solución

Verifica si la política que tardó mucho tiempo en responder y si hay algún código personalizado que pueden tardar mucho tiempo en procesarse. Si existe ese código, ve si puedes corregir y optimizar el código identificado.
Si no hay ningún código personalizado que pueda causar un tiempo de procesamiento alto, comprueba si el mensaje Los procesadores están experimentando un uso elevado de CPU o memoria:
1. Si algún Message Processor tiene un uso elevado de CPU, genera tres conversación dumps cada 30 segundos con el siguiente comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Si algún Message Processor tiene un uso elevado de memoria, genera un volcado de montón con el siguiente comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Usa el siguiente comando para reiniciar el Message Processor. Esto debería reducir la capacidad y Memory.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Supervisa las llamadas a la API y confirma si el problema persiste.
5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona la conversación. Registros de volcados, volcado de montón y Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudarlos investigar la causa del alto uso de CPU/memoria.

Diagnostica problemas con la supervisión de API

La supervisión de API te permite aislar rápidamente las áreas problemáticas para diagnosticar errores, rendimiento y latencia, así como su origen. como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Lee una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 504 supere un umbral en particular.