Como encontrar a linha que torna um checkout lento.
Quando uma loja online parece lenta e os servidores estão parados, a espera é normalmente uma chamada síncrona ao sistema de outra pessoa dentro do caminho do pedido. O método que transforma o «parece lento» num ficheiro e numa linha.
Neste artigo 8 secções
As queixas de que uma loja online está lenta são do tipo vago, de reputação. Sem stack trace, sem número de linha, apenas um comerciante a transmitir que um comprador o disse, e a aritmética por baixo: um checkout lento é um carrinho abandonado, e um carrinho abandonado é receita a sair porta fora a meio da compra. Por isso a primeira tarefa não é corrigir nada. É transformar uma sensação numa localização.
- Meça a plataforma sob a carga que está a falhar, não num momento calmo: CPU, load, memória, disco, em todas as camadas. Se todas as camadas estão paradas, a espera vive na aplicação ou em algo que ela chama.
- Não confie na página inicial em cache. É servida pela CDN e não prova nada sobre o carrinho e o checkout, que correm código de aplicação ao vivo em cada pedido.
- Capture todos os pedidos mais lentos do que um limiar e agrupe os stack traces por onde cada pedido está bloqueado, não por onde começou. Um grupo sobressai acima dos restantes, e é normalmente uma chamada síncrona a um sistema que a loja não opera.
- Entregue o ficheiro exato, a linha exata e a correção: um timeout curto com fallback, a chamada externa movida para um background job, e as queries por baixo dela com índices para fazerem seek em vez de scan.
A queixa chega como uma sensação
A formulação é de reputação, não técnica: um comprador disse ao comerciante que o site parecia lento, e o comerciante está a passar a mensagem. Para uma loja online, «checkout lento» não é um pormenor: são carrinhos abandonados no passo do pagamento, o sítio mais caro de todo o website para perder alguém. Isso enquadra a urgência, mas não aponta para lado nenhum. Lento é uma sensação, não uma localização.
Um alarme de recursos diz-lhe onde olhar. «O site está lento» não lhe diz nada: pode ser a rede, o host, a base de dados, a aplicação, ou um terceiro que a loja nem sequer opera. Antes de o poder corrigir tem de transformar uma sensação num número de linha. O resto disto é o como.
Meça primeiro a plataforma sob a carga que falha
Comece pela plataforma, medida sob a carga exata que está a falhar: CPU, load average, memória livre, utilização de disco, na camada web e na base de dados. Leia-os enquanto a lentidão está a acontecer, não a partir de um dashboard com a média de uma semana calma. Se todas as camadas estão paradas, a espera vive na aplicação ou em algo que ela chama, e o resto do método é descobrir o quê.
É aí que muitos diagnósticos param. «É a aplicação» é verdadeiro e inútil para um comerciante: ilibar o host deixa a loja exatamente tão presa como antes. O dono de uma loja online não quer saber que é a aplicação. Quer saber que linha, e porquê. Por isso o método continua para dentro de código que não é nosso para corrigir, porque encontrar a linha é o verdadeiro entregável.
A página inicial vai tentar escondê-lo
A primeira coisa que uma verificação rápida mostra parece tranquilizadora, e é essa a armadilha. A página inicial, em cache na CDN, responde depressa. Se verificar uma loja carregando a sua primeira página, conclui que está tudo bem e fecha o ticket. Mas uma página inicial em cache não prova nada sobre o checkout, porque a dor vive apenas nos caminhos que não podem ser postos em cache: o carrinho dinâmico e o checkout, onde a loja corre o seu código real em cada pedido.
| A página inicial em cache | O caminho do checkout |
|---|---|
| Servida pelo edge da CDN | Corre código de aplicação ao vivo de cada vez |
| WHERE THE PAIN LIVESRápida em todas as verificações rápidas | Onde vive realmente cada segundo da espera |
| Parece perfeitamente saudável | Nunca tocado por uma verificação rápida da página inicial |
Agrupe por onde bloqueia, não por onde começa
A jogada que abre o caso transforma ruído numa confissão. Em vez de adivinhar, capture todos os pedidos mais lentos do que um limiar em todos os nós web, depois agrupe os stack traces pela única coisa que importa. Não por onde cada pedido começou (todos começam num URL), mas pela linha exata onde cada pedido está bloqueado, parado à espera. Agrupe milhares de pedidos lentos pelo seu ponto de bloqueio e as adivinhas acabam. Um grupo sobressai acima dos restantes, e numa loja online é normalmente uma chamada de saída ao vivo para um sistema que a loja não opera: uma verificação de stock, uma consulta de preço, uma pontuação de fraude, um ERP, dentro da validação da encomenda. Uma chamada à base de dados que alimenta a mesma integração é normalmente o grupo seguinte.
Leia um pedido bloqueado de cima a baixo
O stack de um pedido bloqueado mostra toda a cadeia desde o ponto de entrada até à chamada externa de que está à espera: o botão de pagamento no topo, a validação da encomenda no meio, e no fundo uma chamada para uma máquina noutra rede, onde o pedido fica até essa máquina responder. É essa a imagem a mostrar ao comerciante, porque não precisa de interpretação: uma pessoa a tentar dar dinheiro à loja está à espera de um sistema que a loja não opera antes sequer de a encomenda validar.
Depois leia a configuração do cliente para essa chamada. O teto da espera é uma única linha: o seu timeout. Um timeout de cliente definido em minutos, onde o caminho de pagamento precisa de segundos, significa que um comprador pode ficar retido no botão de pagamento durante o tempo que o parceiro demorar a responder, e o dia lento do parceiro passa a ser o dia da loja.
“Um comprador a tentar pagar está à espera de uma máquina que a loja não opera, numa rede que a loja não opera, antes sequer de a encomenda validar.”
Verifique as queries por baixo
O slow log da base de dados aponta normalmente para a mesma integração: as queries que a alimentam estão a fazer um varrimento em vez de seek, e estão no mesmo caminho. A chamada externa é lenta, as queries por baixo dela são lentas, e ambas se interpõem entre o comprador e a encomenda. Corrigir a chamada sem as queries deixa o segundo estrangulamento no lugar.
Não reescrevemos o seu checkout. Entregamos-lhe a linha.
Não reescrevemos o checkout de um cliente: é código dele, lógica de negócio dele, risco dele. O que entregamos é mais útil e mais difícil de obter: o ficheiro exato, a linha exata e a correção concreta. Três movimentos, por ordem.
Limite o timeout
: Corte o timeout para poucos segundos com um fallback gracioso, para que um parceiro lento degrade um número de stock em vez de congelar todo o pagamento.
Tire-a do caminho do pedido
: Mova a chamada externa para fora do pedido ao vivo, para um background job. O pagamento de um comprador não deve esperar, ao vivo, pela resposta de um terceiro.
Corrija as queries por baixo
: Crie índices e reescreva as queries que alimentam a integração, para que os dados por trás dela deixem de ser um segundo estrangulamento.
- Uma chamada ao vivo a um sistema externo dentro da validação da encomenda
- Um timeout medido em minutos no passo do pagamento
- O comprador à espera no botão de pagamento
- Full-table scans a correr inline com o checkout
- A chamada externa movida para um background job
- Um timeout de poucos segundos com um fallback gracioso
- O botão de pagamento responde no orçamento de tempo da própria plataforma
- As queries com índices e reescritas
A lição
Um servidor saudável e parado quase nunca é onde a lentidão vive. Quando a plataforma está calma e o comprador está à espera, a espera está na camada da aplicação ou em algo que ela chama, e o método acima encontra que linha.
Mantenha as chamadas síncronas a terceiros fora do caminho do pedido. Dê aos sistemas externos um timeout curto e um fallback, e faça o trabalho real num background job. O caminho do pedido pertence ao comprador.
Respostas diretas
Porque é que o meu checkout é lento quando o resto do site é rápido?+
Normalmente porque a parte rápida está em cache e a parte lenta não. Uma página inicial servida por uma CDN responde depressa e não lhe diz nada sobre o checkout, que corre o seu código de aplicação ao vivo em cada pedido, incluindo qualquer chamada a terceiros que esteja no caminho do pagamento. Verifique o carrinho dinâmico e o checkout, não a primeira página.
Um checkout lento é um problema de hosting ou um problema da aplicação?+
Vale a pena provar, não presumir. Meça a camada web e a base de dados sob a mesma carga real: CPU, load, memória, disco. Se nada está privado de recursos, a espera está na aplicação ou em algo que ela chama, e o passo seguinte é capturar os pedidos lentos e ler onde bloqueiam.
O que é uma chamada síncrona a terceiros no caminho do checkout?+
É quando o seu checkout bloqueia e espera, ao vivo, por um sistema externo antes de deixar a encomenda prosseguir: um ERP, um serviço de stock, uma pontuação de fraude, verificados dentro da validação da encomenda. Se esse parceiro estiver lento, o seu comprador espera exatamente o mesmo tempo que ele, até ao timeout configurado, e um timeout definido em minutos é um teto medido em minutos.
Como descobrem que linha está a tornar uma página lenta?+
Capturamos todos os pedidos mais lentos do que um limiar em todos os nós web, depois agrupamos os stack traces pela linha exata onde cada pedido está bloqueado, não por onde começou. O maior grupo é a sua resposta.
Corrigem o meu código por mim?+
Não reescrevemos o seu checkout: é a sua lógica de negócio. Entregamos-lhe o ficheiro exato, a linha exata e a correção concreta: encurte o timeout com um fallback, mova a chamada a terceiros para um background job, e nós criamos os índices e reescrevemos as queries lentas por baixo dela. O diagnóstico, entregue com precisão, é o produto.
Um botão de pagamento deve chamar diretamente um ERP ou outro terceiro?+
Mantenha-o fora do caminho do pedido. Um sistema em infraestrutura que não controla não deve interpor-se entre o comprador e o pagamento. Dê-lhe um timeout curto e um fallback gracioso para que possa falhar sem derrubar o checkout, e mova a chamada real para um background job.
Há algo lento no seu checkout. Vamos encontrar a linha.
Fale com um engenheiro que lê o seu caminho lento até ao ficheiro e à linha, e que o diz com clareza quando a resposta vive no seu próprio código.
Fale com um engenheiroA disciplina aqui é a mesma que está por trás de duas outras leituras: como dimensionar um servidor, em que a maioria das pessoas precisa de menos do que pensa, e porque é que um servidor novo tem benchmarks mais lentos do que o antigo quando não é.
Chegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro