Configurar
Configurei canais Django dentro de um contêiner docker no servidor Ubuntu 20.04 OVH VPS (8vCore, 16Go RAM). Para rodar canais Django eu usei daphne. Versões:
Django==3.1.4
channels==3.0.2
daphne==3.0.1
Usei Docker-compose com uma imagem para Daphne-Apache, uma imagem para Mysql, uma imagem para Redis.
Emitir
Usei o Locust para verificar o desempenho de carregamento do aplicativo. Quando tenho mais de 10rq/s, o servidorTempo de resposta HTTPfica enorme (> 10 segundos) e o aplicativo fica indisponível.
Onde está o gargalo? O que poderia melhorar o desempenho?
Informação extra
- Nota 1: Reduzi as consultas SQL para uma quantidade muito baixa, cerca de 5 por página.
- Nota 2: Na página de informações do VPS, CPU, Mem e largura de banda não são totalmente utilizados.
- Nota 3: Eu sirvo arquivos estáticos com o Apache Alias, mas quando o aplicativo está sobrecarregado, até mesmo os arquivos estáticos demoram para carregar.
- Nota 4: O erro que recebo quando há muita carga
ConnectionError(ProtocolError('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))
Eu pesquisei e descobri usando processos múltiplos comsupervisorouKubernetesPoderia ajudar. Mas quero ter certeza de que tudo está normal antes de evoluir para isso.
Posso compartilhar arquivos de projeto docker-compose.yml, routing.py, settings.py, mas não parece útil para mim por enquanto.
Responder1
Obrigado, aqui a saída dos comandos
A) Executado no root do Ubuntu executando 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) Executado no contêiner mysql: SHOW GLOBAL STATUS LIKE '%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 VARIÁVEIS GLOBAIS 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 STATUS GLOBAL COMO '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+--------------------------------+-------+
E) MOSTRAR STATUS GLOBAL COMO 'tempo de atividade';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 544 |
+---------------+-------+