O que fazemos · Dados e web: Auditorias de desempenho de aplicações web
Quando um site está lento, a resposta fácil é «acrescentem mais servidores». A nossa é medir cada camada, encontrar a única coisa que está realmente a travar os pedidos e corrigi-la, com números antes e depois. Muitas vezes os servidores revelam-se ociosos e a causa está algures onde ninguém estava a olhar.
O que é
Uma investigação estruturada de uma aplicação web lenta ou instável, de fora para dentro. Recebe um relatório com a nossa marca que identifica a camada da causa raiz (infraestrutura, aplicação ou terceiros), mostra as evidências de cada camada e lista as correções por ordem de prioridade. Onde a correção nos cabe a nós, aplicamo-la e medimos de novo.
Cobrimos WordPress, Magento, PrestaShop, Laravel e PHP à medida, em Linux simples, Plesk e cPanel com CloudLinux, atrás de nginx, LiteSpeed ou Apache.
Como o construímos
Primeiro a infraestrutura, para a confirmar ou excluir. Provamos se os servidores estão ocupados ou ociosos enquanto as páginas estão lentas. Se as CPU estão maioritariamente ociosas e a base de dados responde a partir da memória, acrescentar hardware não vai ajudar, e dizemo-lo.
Cronometragem de fora para dentro. Cronometramos os pedidos através do CDN, no edge e no origin, com e sem cache, para sabermos onde se gastam os segundos antes de ler um único log.
PHP, por ponto de bloqueio. Os slow logs do PHP-FPM são agrupados pela função em que cada pedido lento estava de facto preso. Isso transforma «o site está lento» em «quarenta por cento do tempo lento é uma única chamada externa».
Base de dados, por evidência. Slow query logs com planos EXPLAIN, análise de locks e comportamento do buffer pool. Dimensionamos o buffer pool do InnoDB ao working set, corrigimos buffers por ligação definidos demasiado grandes e encontramos as queries sem limite e os table scans que realmente queimam CPU.
Cada dependência externa. Gateways de pagamento, APIs de ERP e de stock, servidores de licenças, fontes e analytics: sondamos cada uma, porque uma chamada síncrona a um terceiro lento trava a página tão seguramente como uma query lenta.
Correções que duram. Tamanhos de pool definidos a partir da exaustão de workers medida, timeouts de terminação de pedidos e tetos de memória para que um único pedido mal formado não possa derrubar o pool, e limites de buffer no nginx e no Varnish que acomodam cookies e headers reais.
Do que o protege
- Pagar por mais hardware quando o hardware não é o problema.
- Uma única definição mal configurada na base de dados a transformar um servidor saudável num incêndio de CPU ou de I/O de storage.
- Anos de reinícios agendados a fazer as vezes de uma causa raiz.
- Checkouts lentos causados por um terceiro que não sabia estar no caminho do pedido.
- Discussões entre hosting, developers e fornecedores sem dados em cima da mesa.
Na prática
A loja PrestaShop de um retalhista de artigos desportivos. Milhares de pedidos por dia demoravam mais de quatro segundos enquanto os servidores web estavam maioritariamente ociosos. Atribuímos cerca de 40 por cento do tempo lento a uma chamada síncrona de stock ao ERP com um timeout muito longo, 24 por cento a queries que percorriam milhões de linhas e 12 por cento à navegação por facetas. O cliente recebeu um relatório com a nossa marca, com evidências por camada e uma lista de correções priorizada para os seus developers.
Porquê a EuroVPS
- Medimos antes de recomendar, e medimos de novo depois da correção.
- Lemos a stack inteira: rede, storage, base de dados, PHP, servidor web, CDN e terceiros.
- Os relatórios identificam uma causa e uma camada, com evidências sobre as quais os seus developers podem agir.
- Aplicamos nós próprios o lado da infraestrutura da correção, de forma segura e reversível.
- Resultados honestos: se os seus servidores estão bem, dizemo-lo, mesmo quando vender hardware seria mais fácil.
Perguntas frequentes
Precisam de acesso ao nosso código? Não. Trabalhamos a partir dos logs do servidor, da base de dados e de acessos, e de cronometragem feita de fora. Se a causa estiver no código, apontamos o plugin, endpoint ou query exato.
Conseguem auditar um site alojado noutro lado? Sim, com o acesso necessário para ler logs e métricas. Muitas auditorias terminam numa migração; algumas não precisam de nenhuma.
Quanto tempo demora uma auditoria? Muitas causas são encontradas em horas. Um relatório completo com todas as camadas medidas demora normalmente alguns dias, consoante a intermitência do problema.
Vão alterar alguma coisa sem perguntar? Não. Cada alteração é acordada, aplicada com um caminho de rollback, e medida.
O que recebemos? Um relatório com a nossa marca, com as medições, a camada da causa raiz e uma lista priorizada de correções com responsáveis.
Site lento, servidores ociosos? Fale com um engenheiro.
Serviços relacionados
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.