Diferença de performance de uma aplicação com cenários idênticos

[matheusbattisti 0]

Neste fim de semana fizemos deploy de uma aplicação com base no framework Magento, que foi exaustivamente testada em vários cenários, com alta carga de usuários fazendo várias requisições ao banco de dados, como consultas, atualizações e inserções, todo o percurso dos clientes finais foi simulado.

Nos testes as configurações eram idênticas as que estavam na hora do deploy, a única diferença era o subdomínio, que estavamos usando um de homologação e depois apontamos para o www, e para nossa surpresa a aplicação ficou totalmente instável, apresentando erros de banco de dados, na verdade apenas um erro:

MySQL error 2006: mysql server has gone away

Este erro ocorreu em diversas tabelas, e na aplicação de testes não ocorreu nem uma vez, com 50 usuários simultâneos fazendo compras, e na hora do deploy estavamos com 20 usuários (segundo o analytics).

A configuração da infra é:

- 2 Web servers
- 1 File server
- RDS
- Servidor para Redis

A pergunta é: Como é possível que em casos idênticos de configuração a aplicação se comportou tão diferente? o subdomínio tem alguma influência nisto?

Obs: se precisarem de mais detalhes, favor solicitar

Obrigado

[Matheus Tavares 167]

Olá!

 

Dificilmente esse problema seja de performance, ainda mais com os testes que você citou, de 20 ou 50 usuários simultâneos, pois esse número não é tão grande. Além disso você disse que estava rodando sem problemas em outro domínio.

Você está usando qual máquina da AWS? t2.nano? Pois creio que qualquer máquina superior à ela suporte tranquilo essa quantidade de usuários, mas não custa testar uma máquina mais forte para ver se há diferença.

 

Você citou que está usando a RDS, e por isso eu assumo que sua arquitetura esteja toda na AWS. Como você está rodando as máquinas da aplicação? Diretamente com o EC2, com ElasticBeanstalk ou com outro serviço, como o ECS (Docker)?

Você deve saber, mas não custa lembrar que o ElasticBeanstalk possui um leque de variáveis que podem ser definidas e alteram o comportamento da sua aplicação, através das ebextensions. Um exemplo de definição que pode ser feita é:

option_settings:
  aws:elasticbeanstalk:container:php:phpini:
    document_root: '/public'
    memory_limit: '256M'
    zlib.output_compression: 'On'
    allow_url_fopen: 'On'
    display_errors: 'Off'
    max_execution_time: 60

 

Se você utiliza o Composer, deveria indicar que a instalação é para produção e quer otimizar o autoloader, assim:

option_settings:
  aws:elasticbeanstalk:container:php:phpini:
    composer_options: '--no-dev --optimize-autoloader'

 

Como surgem problemas relacionados ao banco, não custa perguntar também: qual máquina você está usando no RDS? Já tentou aumentar o poder computacional dela? Pois pelo erro reportado, quem está com problemas em atender às requisições é o banco. 

 

1 hora atrás, matheusbattisti disse:

o subdomínio tem alguma influência nisto?

Aí que tá, não deveria ter influência nenhuma.

Meu maior palpite é algum problema relacionado à rede/dns/vpc. Talvez no seu novo deploy você tenha esquecido de dar acesso ao RDS ou outro serviço à máquina nova de produção.

 

Você podia também rodar um benchmark temporário (na máquina de produção mesmo) para ver se encontra o ponto específico que está causando problemas. Aconselho fortemente dar uma olhada no blackfire. É bem fácil rodar ele.

 

Boa sorte...