Stress con documentos grandes

[dquiroga]

Hola, nos esta pasando que el sistema experimenta degradación cuando se hace vista previa de documentos con adjuntos "grandes".  Estamos hablando de un pdf adjunto, entre 30 y 50 Mb, con 200 o 300 paginas de fotos, escaneos, etc.   En un principio tuvimos problemas para autorizarlos ya que se nos caia el sistema, pero lo solucionamos asignando suficiente cpu y ram al contenedor de sudocu_api_server.  Le terminamos dando 3 cpu y 13GB de ram solo a ese contenedor y en principio dejo de caerse.... pero en el momento en que se hace una vista previa de un documento, vemos que el servidor host (donde esta docker) se lleva todo el cpu con un proceso node... y el sistema deja de responder a otros usuarios por varios segundos  (y salen carteles rojos con errores varios de acceso al api, que no se pueden obtener listados, etc. etc.)... Luego de que se abre el doc, todo parece seguir normal.

... posterior a esto quisieron subir archivos con 100Mb....  y ahi ya se vuelve a caer el sudocu-api-server. 

¿hay alguna experiencia en esta direccion haciendo alguna prueba de stress con herramientas tipo Apache Benchmark (https://httpd.apache.org/docs/2.4/programs/ab.html) o alguna similar?

Me serviria mucho si alguien me orienta en como probar estas cuestiones y monitorear el comportamiento de los contenedores a ver donde y cuando se dan los fallos, y que tanta carga se puede aguantar el sistema.

Saludos!

[dquiroga]

Por si a alguien le sirve el tip...

encontramos que sudocu-api-server, por mucha memoria que le asignaramos, daba error cuando node intentaba usar mas de 2G (asi lo acusó en lso logs) .... investigando un poco vimos que tenia que ver con la variable max-old-space-size que afecta la memoria que puede usar el motor javascript V8 (que usa nodejs).  Le configuramos esa variable para que use mas memoria y las cosas mejoraron mucho.

Para ver que valor tiene actualmente la variable, hay que entrar al contenedor de api-server y correr este comando:

node -e 'console.log(`node heap limit = ${require("v8").getHeapStatistics().heap_size_limit / (1024 * 1024)} Mb`)'

Por defecto esta en 2G.

Y para asignarle otro valor, se puede setear la variable de ambiente en el archivo sudocu.yml, donde esta el contenedor de api:

environment:
      NODE_OPTIONS: "--max-old-space-size=8192"

No se si es la solución definitiva, pero con este cambio  no volvimos a tener problemas todavia.

Saludos!

[dquiroga]

Por si sirve tambien este otro tip ....

Siguiendo en la misma línea, nos aparecieron un par de expedientes con varios documentos y muchos adjuntos,  y nos empezó a dar problemas sudocu-api-server ya no por falta de memoria, sino por bloqueo o timeout.   Al momento de querer bajar el zip del expediente, el container con el servicio de  api se llevaba todo el CPU y luego de estar corriedo un rato aparecia un error de timeout. Mientras tanto sudocu dejaba de responder a otros usuarios y todo quedaba medio bloqueado.

Lo solucionamos modificando una variable (UV_THREADPOOL_SIZE) que afecta el comportamiento de la libreria libuv que nodejs usa internamente para operaciones con zlib, fs, dns, etc:

https://nodejs.org/api/cli.html#uv_threadpool_sizesize
https://docs.libuv.org/en/latest/threadpool.html

Agregamos la variable de ambiente en sudocu.yml, que finalmente nos quedó asi:

environment:
      TZ: "America/Buenos_Aires"
      NODE_OPTIONS: "--max-old-space-size=8192"
      UV_THREADPOOL_SIZE: "512"

Con esto solucionamos el problema de timeout y el sistema sigue respondiendo a otros usuarios mientras arma el zip, si bien se nota alguna demora en las respuestas y se aprecia alguna lentitud.

Saludos!