Atualmente, estou executando um servidor Apache com HTTP/2 habilitado como proxy reverso para meu aplicativo da web. Percebi uma lentidão significativa ao solicitar um grande número de miniaturas pequenas (cada uma com aproximadamente 60 KB) por meio desta configuração. Estranhamente, essa desaceleração começou a ocorrer após a mudança de HTTP/1.1 para HTTP/2, embora o HTTP/2 deva melhorar o desempenho(especialmente neste caso, já que solicitar muitos arquivos pequenos é um ótimo caso de uso para todas as coisas sofisticadas de multiplexação HTTP/2 faz).
Ao solicitar imagens sequencialmente não notei lentidão, mas apenas quando o cliente arquiva muitos arquivos de uma vez (cerca de 200).
O Bakend fala apenas HTTP/1.1 e é acessível usando o proxy reverso. As miniaturas são pré-armazenadas em cache no disco.
Aqui está o gráfico em cascata do Chromium para HTTP/2: Waterfall HTTP/2
E para HTTP/1.1: Cascata HTTP 1.1
Como você pode ver nas imagens, as solicitações HTTP/2 não estão mais paralisadas, mas o tempo geral aumentou.
Quaisquer dicas ou dicas sobre como depurar ainda mais isso seria ótimo
(Isso deveria ser um comentário - mas espaço limitado)
1.) O primeiro lugar para verificar quando um serviço não está se comportando conforme o esperado é nos logs. Mas os formatos de log padrão não capturam informações úteis de tempo - você deve adicionar pelo menos %D em httpd
2.) Eu adoro o Apache httpd como servidor de origem, mas não é o ideal como proxy reverso
3.) Ao pedir ajuda sobre o software que não funciona conforme esperado, é uma boa ideia fornecer as informações da versão e os detalhes de como ele está configurado
4.) O que você nos mostrou parece mais algo em conformidade com o limite do HTTP/1.1 em solicitações simultâneas do que algo lento (mas não vi esse comportamento do mod_proxy)
Acho que isso tem a ver com uma combinação de atingir o limite máximo de fluxo de sessão do Apache, com a forma como as imagens fora da tela (e outras solicitações de prioridade mais baixa) são tratadas pelo Chrome em HTTP/2 e superior, quando isso acontece.
Por padrão, mod_http2 permite no máximo 100 streams ao mesmo tempo. Depois disso, as solicitações ficarão na fila antes de serem enviadas.
Tenho um teste semelhante aqui (embora com imagens menores): https://https.tunetheweb.com/performance-test-360/
Ao testar em uma conexão 4G:
Fazendo os mesmos testes em HTTP/1.1, você não vê este efeito de escada:
No entanto, o HTTP/2 é consideravelmente mais rápido que o HTTP/1.1 em ambos os testes (9,775 segundos contra 13,864 segundos no celular e 4,129 segundos contra 13,622 segundos no desktop). É possível que com imagens maiores essa compensação não funcione tão bem e o HTTP/2 acabe sendo mais lento.
Portanto, sugiro repetir seus testes com todas as imagens na tela. Ou, alternativamente, aumentar o
H2MaxSessionStreamstamanho máximo para um mais adequado ao seu site.Executar novamente o teste móvel após limitar
H2MaxSessionStreamsa 400 mostra que ele não o limita: https://www.webpagetest.org/result/231001_BiDcBW_70Q/1/details/#waterfall_view_step1No entanto, quando muitas solicitações estão em andamento ao mesmo tempo, você acaba enfrentando todos os tipos de problemas de priorização. Os servidores devem enviar um pouco de cada resposta em rodízio? Ou envie as primeiras respostas por extenso na ordem em que foram solicitadas. Muito já foi escrito sobre isso (veja este post por exemplo) e a resposta depende de muitas coisas. Para HTML e imagens (e em particular imagens progressivas), enviar bits de cada vez pode ser melhor, pois podem ser processados pelo navegador à medida que chegam. Para outros recursos onde todos os recursos são necessários antes de serem usados (pense em CSS e JavaScript), enviar peças não é útil e seria melhor enviar as respostas em ordem.
Portanto, eu recomendo alterar muito os padrões aqui, pois pode não ser tão útil. Além disso, exigirá mais recursos no navegador e no servidor. Se isso for devido a imagens fora da tela, isso pode não ser tão ruim quanto seu teste mostra, pois o impacto para o usuário pode ser muito menor.
Também aconselho tentar reduzir o número de recursos em sua página. Mais de 200 arquivos é MUITO para lidar. HTTP/2 torna as solicitações mais baratas, mas não gratuitas.