Estoy probando la carga de un servidor gunicorn (usa trabajadores de Uvicorn con fastapi) en la máquina AWS EC2 en la que ingresé y el puerto asignado (haciendo ssh -L 8000:localhost:8000 ), para todas las solicitudes en el puerto 8000 en mi máquina local para enrutarse a la máquina EC2.
Y estoy usando k6 para generar tráfico artificial (prueba de carga) para el servidor gunicorn en la instancia EC2 desde mi máquina local. Con SOLO 500-800 vus, más del 46 % de las solicitudes siempre fallan, pero el uso de la CPU de la máquina EC2 nunca supera el 30 % para ninguno de los 8 núcleos (de htop ). Estoy usando una máquina c5a.2xlarge (tiene 4 núcleos u 8 hilos).
Así es como estoy lanzando el gunicorn desde la terminal (debido a la configuración, el gunicorn se inicia con 4 trabajadores):
$ gunicorn api.main:app --worker-class uvicorn.workers.UvicornWorker --user dockerd --capture-output --keep-alive 0 --port 8000y el archivo de configuración que estoy usando es del uvicorn-gunicorn-docker de tiangolo
Esta es una aplicación fastapi, que sirve un modelo scikit-learn sin llamadas a la base de datos ni nada por el estilo. Entonces, esta es una aplicación completamente vinculada a la CPU.
Me complace proporcionar más información según sea necesario.
¿Dónde y qué cambios hago en uvicorn o gunicorn para poder atender muchas solicitudes con la menor tasa de fallas posible, mientras uso todos los recursos al máximo (o en la medida necesaria).
Verifique el promedio de carga en su instancia. Es posible que la CPU no esté al máximo porque tienes el disco que se está convirtiendo en el cuello de botella. Si su promedio de carga indica que se acumulan varios trabajos pero el porcentaje de CPU no aumenta, podría significar latencia del disco.
Es mejor eliminar todos los registros. el promedio de carga está disponible en "sudo htop". puedes buscar eso. Ahora estoy bastante seguro de que su problema es el disco.