Fix latencia en GCP en Cloud Endpoint con Request body superior al buffer por defecto de Nginx .

 El síntoma es el siguiente:

1.- Existe mucha concurrencia en request en los endpoint de metadata, cuando se ejecutan acciones de reproceso de información el cuerpo del mensaje Body supera,
el tamaño por defecto del buffer en el Cloud Endpoint (request body size), la versión que estamos usando es la  1.32.0. 

2.- Al superar el tamaño del buffer el  nginx  es obligado a usar disco para respaldar la petición en la VM creada, para no perder el request antes de que llegue al Backend, en el Balanceador de Carga.
3.- Por efecto de usar disco en vez de memoria RAM disponible del Cluster, la latencia crece.

4.- Por este círculo vicioso estamos perdiendo peticiones sin llegar al Backend, el cliente pierde la conexión el balanceador limpia los request con código HTTP 499 al cumplirse el timeout del Backend Config , el cliente recibe como resultado un  HTTP 502.



Version actual del Docker Image de los endpoint:
image: gcr.io/endpoints-release/endpoints-runtime:1.32.0

Investigar si la nueva versión proporciona una mejora y si conviene una migración de ESP and ESPv2 Beta

Favor aplicar en el pipeline de los Endpoint modificando el Jenkins File el tamaño personalizado del buffer de los endpoints ya que por defecto es de solo 128k:

github.com/cloudendpoints

La documentación indica lo que {{client_body_buffer_size}}hace:

Establece el tamaño del búfer para leer el cuerpo de la solicitud del cliente. En caso de que el cuerpo de la solicitud sea más grande que el búfer, todo el cuerpo o solo una parte se escribe en un archivo temporal. De forma predeterminada, el tamaño del búfer es igual a dos páginas de memoria. Esto es 8K en x86, otras plataformas de 32 bits y x86-64. Suele ser de 16K en otras plataformas de 64 bits.


Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Here is a simple example where an Ingress sends all its traffic to one Service:





Esta memoria está en uso sólo mientras se carga una solicitud; una vez que se pasa al backend, la memoria se libera nuevamente. Si una solicitud es mayor que este valor, irá a un archivo temporal y aparecerá una advertencia en el registro de errores.

Esto significa que debe tener suficiente RAM para almacenar cualquier carga simultánea, o su servidor comenzará a intercambiarse.

El impacto en el rendimiento de esto probablemente no sea tan grande, a menos que tenga una gran limitación de memoria y obtenga muchas cargas al mismo tiempo

https://github.com/cloudendpoints/endpoints-tools/commit/5f4bfdcc26926eb1120b8b1cc282284db4334d48

Solución:

  1. Solución más barata, especificar una configuración en el Ingress, personalizada de Nginx cuando se haga deploy con la opción del tamaño del buffer en 10MB.:
    nginx.ingress.kubernetes.io/client-body-buffer-size: 5m
    nginx.ingress.kubernetes.io/proxy-body-size: 15m
    nginx.ingress.kubernetes.io/proxy-buffering: "on"
    nginx.org/client-max-body-size: 15m

  2. Solución más cara, habilitar la API https://apigee.google.com/edge y habilitar las configuraciones:


No hay comentarios.:

Problemas de activación WIFI6 en LG_OLED55CXPSA

  Mi experiencia con este TV  ah sido impecable hasta ahora, llevaba un uso normal y no tenia que usar la conexión por wifi ya que tengo una...