Configuración
He configurado los canales Django dentro de un contenedor acoplable en el servidor Ubuntu 20.04 OVH VPS (8vCore, 16Go RAM). Para ejecutar django-channels utilicé daphne. Versiones:
Django==3.1.4
channels==3.0.2
daphne==3.0.1
Utilicé Docker-compose con una imagen para Daphne-Apache, una imagen para Mysql, una imagen para Redis.
Asunto
Utilicé Locust para comprobar el rendimiento de carga de la aplicación. Cuando tengo más de 10rq/s, el servidortiempo de respuesta HTTPse vuelve enorme (> 10 segundos) y la aplicación deja de estar disponible.
¿Dónde está el cuello de botella? ¿Qué podría mejorar el rendimiento?
Información extra
- Nota 1: He reducido las consultas SQL a una cantidad muy baja, aproximadamente 5 por página.
- Nota 2: En la página de información de VPS, CPU, Mem y ancho de banda no se utilizan por completo.
- Nota 3: Sirvo archivos estáticos con Apache Alias, pero cuando la aplicación está sobrecargada, incluso los archivos estáticos tardan en cargarse.
- Nota 4: El error que aparece cuando hay demasiada carga
ConnectionError(ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))
Busqué y descubrí usando múltiples procesos consupervisoroKubernetespodría ayudar. Pero quiero estar seguro de que todo es normal antes de pasar a eso.
Puedo compartir archivos de proyecto docker-compose.yml, route.py, settings.py pero no me parece útil por ahora.
Respuesta1
Gracias, aquí la salida de los comandos.
A) Ejecutado en la raíz de Ubuntu ejecutando Docker: ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62405
max locked memory (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62405
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
B) Ejecutado en el contenedor mysql: MOSTRAR ESTADO GLOBAL COMO '%open%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Com_ha_open | 0 |
| Com_show_open_tables | 0 |
| Innodb_num_open_files | 29 |
| Open_files | 14 |
| Open_streams | 0 |
| Open_table_definitions | 113 |
| Open_tables | 114 |
| Opened_files | 149 |
| Opened_table_definitions | 113 |
| Opened_tables | 121 |
| Slave_open_temp_tables | 0 |
| Table_open_cache_hits | 25 |
| Table_open_cache_misses | 121 |
| Table_open_cache_overflows | 0 |
+----------------------------+-------+
C) MOSTRAR VARIABLES GLOBALES COMO '%open%';
+----------------------------+---------+
| Variable_name | Value |
+----------------------------+---------+
| have_openssl | YES |
| innodb_open_files | 2000 |
| open_files_limit | 1048576 |
| table_open_cache | 2000 |
| table_open_cache_instances | 16 |
+----------------------------+---------+
D) MOSTRAR ESTADO GLOBAL COMO '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+--------------------------------+-------+
E) MOSTRAR ESTADO GLOBAL COMO 'tiempo de actividad';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 544 |
+---------------+-------+