Em cache, as miniaturas geradas pelo PHP carregam lentamente

Pergunta Parte A ▉ (100 recompensas, concedidas)
A questão principal era como tornar este site mais rápido. Primeiro, precisamos ler essas cachoeiras. Obrigado a todos por suas sugestões na análise de leitura em cascata. Evidente dos vários gráficos em cascata mostrados aqui é o principal gargalo: as miniaturas geradas pelo PHP. O carregamento de jquery sem protocolo da CDN, recomendado por David, recebeu minha recompensa, apesar de tornar meu site apenas 3% mais rápido no geral, e sem responder ao principal gargalo do site. Hora de esclarecer minha pergunta e outra recompensa:

Pergunta Parte B ▉ (100 recompensas, concedidas)
O novo foco agora era resolver o problema das 6 imagens jpg, que estão causando o máximo do atraso no carregamento. Estas imagens são 6 miniaturas PHP-gerados, pequena e apenas 3 ~ 5 kb, mas o carregamento relativamente muito lentamente. Observe o " tempo até o primeiro byte " nos vários gráficos. O problema permaneceu sem solução, mas James recebeu uma recompensa, que corrigiu o erro de cabeçalho sublinhado pelo RedBot : "Uma solicitação condicional If-Modified-Since retornou o conteúdo completo inalterado". .

Pergunta Parte C ▉ (minha última recompensa: 250 pontos)
Infelizmente, depois que o erro do cabeçalho do REdbot.org foi corrigido, o atraso causado pelas imagens geradas pelo PHP permaneceu intocado. O que diabos essas pequenas miniaturas insignificantes de 3 a 5Kb estão pensando? Todas essas informações de cabeçalho podem enviar um foguete para a Lua e voltar. Todas as sugestões sobre esse gargalo são muito apreciadas e tratadas como uma possível resposta, já que estou preso nesse problema de gargalo já há sete meses. Agradeço antecipadamente.

[Algumas informações básicas no meu site: CSS está no topo. JS na parte inferior (Jquery, JQuery UI, compre o menu awm / menu.js engines, tabs js engine, video swfobject.js) As linhas pretas na segunda imagem mostram o que está iniciando o que carregar. O robô zangado é meu animal de estimação "ZAM". Ele é inofensivo e geralmente mais feliz.]

Cachoeira de carga: cronológica | http://webpagetest.org

Domínios paralelos agrupados | http://webpagetest.org

Cachoeira Site-Perf | http://site-perf.com

Pingdom Tools Cachoeira | http://tools.pingdom.com

Cachoeira GTmetrix | http://gtmetrix.com

Primeiro, o uso desses vários domínios requer várias pesquisas de DNS. É melhor combinar muitas dessas imagens em um sprite em vez de espalhar as solicitações.

Segundo, quando carrego sua página, vejo a maior parte do bloqueio (~ 1,25s) em all.js. Vejo que começa com (uma versão antiga do) jQuery. Você deve referenciar isso na CDN do Google, não apenas para diminuir o tempo de carregamento , mas para evitar uma solicitação HTTP por completo.

Especificamente, as bibliotecas jQuery e jQuery UI mais recentes podem ser referenciadas nesses URLs (consulte esta postagem se você estiver interessado em saber por que omiti o http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Se você estiver usando um dos temas padrão da interface do usuário do jQuery, também poderá extrair o CSS e as imagens do CDN do Google .

Com a hospedagem jQuery otimizada, você também deve combinar awmlib2.jse tooltiplib.jsem um único arquivo.

Se você abordar essas questões, verá uma melhoria significativa.

Eu tive um problema semelhante há poucos dias e eu achei head.js . É um plug-in Javascript que permite carregar todos os arquivos JS paralelos. Espero que ajude.

Estou longe de ser um especialista, mas ...

Em relação a isso: "Uma solicitação condicional If-Modified-Since retornou o conteúdo completo inalterado." e meus comentários.

O código usado para gerar as miniaturas deve verificar o seguinte:

1. Existe uma versão em cache da miniatura.
2. A versão em cache é mais recente que a imagem original.

Se um deles for falso, a miniatura deve ser gerada e retornada, não importa o quê. Se ambos são verdadeiros, a seguinte verificação deve ser feita:

1. Existe um cabeçalho HTTP_IF_MODIFIED_SINCE
2. O horário da última modificação da versão em cache é o mesmo que o HTTP_IF_MODIFIED_SINCE

Se um desses for falso, a miniatura em cache deve ser retornada.

Se os dois forem verdadeiros, um status http 304 deve ser retornado. Não tenho certeza se é necessário, mas também retorno pessoalmente os cabeçalhos de controle de cache, expira e última modificação, juntamente com o 304.

Com relação ao GZipping, fui informado de que não há necessidade de imagens do GZip, portanto ignore essa parte do meu comentário.

Editar: não notei sua adição à sua postagem.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

Também tenho certeza de que seu código precisa verificar o cabeçalho HTTP_IF_MODIFIED_SINCE e reagir a ele. Basta definir esses cabeçalhos e o arquivo .htaccess não fornecerá o resultado necessário.

Eu acho que você precisa de algo assim:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

Uau, é difícil explicar as coisas usando essa imagem. Mas aqui, algumas tentativas:

• os arquivos 33-36 são carregados tão tarde, porque são carregados dinamicamente no swf, e o swf (25) é carregado primeiro completamente antes de carregar qualquer conteúdo adicional
• os arquivos 20 e 21 são talvez (não sei, porque não conheço seu código) bibliotecas carregadas por all.js (11), mas, para que o 11 seja executado, aguarde a página inteira (e os ativos) para carregar (você deve alterar isso para já)
• os arquivos 22-32 são carregados por essas duas bibliotecas, novamente após o carregamento completo

Apenas um palpite simples, porque esse tipo de análise requer muitos testes A / B: seu domínio .ch parece difícil de alcançar (faixas verdes longas antes da chegada do primeiro byte).

Isso significaria que o site .ch está mal hospedado ou que o seu provedor de serviços de Internet não possui uma boa rota para eles.

Dados os diagramas, isso poderia explicar um grande impacto no desempenho.

Em uma nota lateral, há esta ferramenta interessante que pode ajudá-lo a resolver as coisas, dependendo do seu pedido de carregamento de recursos.

Tente executar os testes Y! Slow e Page Speed ​​em seu site / página e siga as diretrizes para resolver possíveis gargalos de desempenho. Você deve obter enormes ganhos de desempenho depois de obter uma pontuação mais alta em Y! Slow ou Page Speed.

Esses testes informam o que há de errado e o que mudar.

Então, seu script PHP está gerando as miniaturas a cada carregamento da página? Primeiro, se as imagens que estão sendo miniaturadas não mudam com tanta frequência, você poderia configurar um cache para que não precise ser analisado sempre que a página carregar? Em segundo lugar, o seu script PHP está usando algo como imagecopyresampled()para criar as miniaturas? Essa é uma downsample não trivial e o script PHP não retornará nada até que isso seja feito. A utilização imagecopymerged()reduzirá a qualidade da imagem, mas acelerará o processo. E quanto de redução você está fazendo? Essas miniaturas têm 5% do tamanho da imagem original ou 50%? Um tamanho maior da imagem original provavelmente está levando a uma desaceleração, pois o script PHP precisa obter a imagem original na memória antes de poder encolhê-la e gerar uma miniatura menor.

Encontrei o URL do seu site e verifiquei um arquivo jpg individual na página inicial. Embora o tempo de carregamento seja razoável agora (161ms), ele está aguardando 126ms, o que é demais.

Seus cabeçalhos modificados pela última vez estão todos definidos para sáb, 01 de janeiro de 2011 12:00:00 GMT, que parece "redondo" demais para ser a data real da geração ;-)

Como o controle de cache é "público, idade máxima = 14515200", cabeçalhos arbitrários da última modificação podem causar problemas após 168 dias.

De qualquer forma, este não é o verdadeiro motivo de atrasos.

Você deve verificar o que o gerador de miniaturas faz quando a miniatura já existe e o que pode consumir tanto tempo verificando e entregando a imagem.

Você pode instalar o xdebug para criar um perfil do script e ver onde estão os gargalos.

Talvez a coisa toda use uma estrutura ou se conecte a algum banco de dados à toa. Eu vi mysql_connect () muito lento em alguns servidores, principalmente porque eles estavam se conectando usando TCP e não soquete, às vezes com alguns problemas de DNS.

Entendo que você não pode postar seu gerador pago aqui, mas receio que haja muitos problemas possíveis ...

Se não houver um motivo realmente bom (geralmente não existe), suas imagens não devem chamar o interpretador PHP.

Crie uma regra de reescrita para o servidor da Web que hospeda a imagem diretamente, se ela for encontrada no sistema de arquivos. Caso contrário, redirecione para o seu script PHP para gerar a imagem. Ao editar a imagem, altere o nome do arquivo das imagens para forçar os usuários que possuem uma versão em cache a buscar a imagem recém-editada.

Se não funcionar, pelo menos você o fará agora, não tem nada a ver com a maneira como as imagens são criadas e verificadas.

Investigue o uso de dados da sessão pelo PHP. Talvez (apenas talvez), o script PHP de geração de imagens esteja esperando para bloquear os dados da sessão, bloqueados pela página principal de renderização contínua ou por outros scripts de renderização de imagem. Isso tornaria todas as otimizações de JavaScript / navegador quase irrelevantes, pois o navegador está aguardando o servidor.

O PHP bloqueia os dados da sessão para todos os scripts em execução, desde o momento em que o tratamento da sessão é iniciado, até o momento em que o script termina ou quando session_write_close () é chamado. Isso efetivamente serializa as coisas. Confira a página do PHP em sessões, especialmente os comentários, como este .

Este é apenas um palpite, já que não examinei o seu código, mas suspeito que as sessões podem estar desempenhando um papel aqui, o seguinte é da entrada do Manual do PHP em session_write_close():

Os dados da sessão geralmente são armazenados após o script ser finalizado sem a necessidade de chamar session_write_close (), mas como os dados da sessão são bloqueados para impedir gravações simultâneas, apenas um script pode operar em uma sessão a qualquer momento. Ao usar conjuntos de quadros em conjunto com sessões, os quadros serão carregados um a um devido a esse bloqueio. Você pode reduzir o tempo necessário para carregar todos os quadros encerrando a sessão assim que todas as alterações nas variáveis ​​da sessão forem concluídas.

Como eu disse, não sei o que seu código está fazendo, mas esses gráficos parecem estranhamente suspeitos. Eu tive um problema semelhante ao codificar uma função de exibição de arquivo de várias partes e tive o mesmo problema. Ao exibir um arquivo grande, não consegui que a funcionalidade de várias partes funcionasse, nem abri outra página até que o download fosse concluído. Ligar session_write_close()corrigiu meus dois problemas.

Você já tentou substituir os thumnails gerados pelo php por imagens regulares para ver se há alguma diferença? O problema pode estar presente - um bug no seu código php que leva à regeneração da miniatura em cada chamada do servidor - um atraso no seu código (sleep ()?) Associado a um problema de relógio - um problema no disco rígido que causa uma condição de corrida muito ruim pois todas as miniaturas são carregadas / geradas ao mesmo tempo.

Acho que, em vez de usar esse script gerador de miniaturas, você deve tentar o TinySRC para uma rápida geração de miniaturas, rápida e hospedada na nuvem. Tem uma API muito simples e fácil de usar, você pode usar como: -

http://i.tinysrc.mobi/ [height] / [width] /http://domain.tld/path_to_img.jpg

[largura] (opcional): - É uma largura em pixels (que substitui o tamanho adaptável ou familiar). Se prefixado com '-' ou 'x', subtrairá ou diminuirá para uma porcentagem do tamanho determinado.

[altura] (opcional): - É uma altura em pixels, se também houver largura. Ele também substitui o tamanho adaptativo ou familiar e pode ser prefixado com '-' ou 'x'.

Você pode verificar o resumo da API aqui

Perguntas frequentes

Quanto o tinySrc me custa?

Nada.

Quando posso começar a usar tinySrc?

Agora.

Quão confiável é o serviço?

Não oferecemos garantias sobre o serviço tinySrc. No entanto, ele é executado em uma grande infraestrutura de nuvem distribuída , oferecendo alta disponibilidade em todo o mundo. Deve ser suficiente para todas as suas necessidades.

Quão rápido é?

tinySrc armazena em cache imagens redimensionadas na memória e em nosso armazenamento de dados por até 24 horas , e não buscará sua imagem original todas as vezes. Isso torna os serviços incrivelmente rápidos da perspectiva do usuário. (E reduz a carga do servidor como um bom efeito colateral.)

Boa sorte. Apenas uma sugestão, já que você não está nos mostrando o código: p

Como alguns navegadores baixam apenas 2 downloads paralelos por domínio, você não pode adicionar domínios adicionais para dividir as solicitações em dois a três nomes de host diferentes. por exemplo 1.imagecdn.com 2.imagecdn.com

Primeiro de tudo, você precisa lidar com If-Modified-Sincesolicitações e de maneira apropriada, como disse James. Esse erro afirma que: "Quando pergunto ao seu servidor se essa imagem foi modificada desde a última vez, ela envia a imagem inteira em vez de um simples sim / não".

O tempo entre a conexão e o primeiro byte geralmente é o tempo que o script PHP leva para executar. É aparente que algo está acontecendo quando esse script começa a ser executado.

1. Você já pensou em criar um perfil? Pode ter alguns problemas.
2. Combinado com o problema acima, seu script pode estar sendo executado muito mais vezes do que o necessário. Idealmente, ele deve gerar miniaturas apenas se a imagem original for modificada e enviar miniaturas em cache para todas as outras solicitações. Você verificou se o script está gerando as imagens desnecessariamente (por exemplo, para cada solicitação)?

A geração de cabeçalhos adequados por meio do aplicativo é um pouco complicada, e eles podem ser substituídos pelo servidor. E você está exposto a abusos, pois qualquer pessoa que envie alguns cabeçalhos de solicitação sem cache fará com que o gerador de miniaturas funcione continuamente (e aumente a carga). Portanto, se possível, tente salvar os polegares gerados, chamar as imagens salvas diretamente de suas páginas e gerenciar cabeçalhos .htaccess. Nesse caso, você nem precisaria de nada .htaccessse o seu servidor estiver configurado corretamente.

Além disso, você pode aplicar algumas das idéias brilhantes de otimização das partes de desempenho desta boa pergunta geral sobre SO sobre como criar sites da maneira certa , como dividir seus recursos em subdomínios sem culinária etc. Mas, de qualquer forma, uma imagem em 3k não deve demorar um segundo para carregar, isso é aparente quando comparado a outros itens nos gráficos. Você deve tentar identificar o problema antes de otimizar.

Você já tentou configurar vários subdomínios no servidor NGINX, especialmente para fornecer dados estáticos, como imagens e folhas de estilo? Algo útil já pode ser encontrado neste tópico .

Em relação às miniaturas atrasadas, tente fazer uma chamada para flush () imediatamente após a última chamada para o cabeçalho () no script de geração de miniaturas. Depois de concluído, gere novamente o gráfico em cascata e veja se o atraso está agora no corpo, em vez dos cabeçalhos. Nesse caso, você precisa dar uma longa olhada na lógica que gera e / ou gera os dados da imagem.

Esperamos que o script que lida com as miniaturas use algum tipo de cache, para que as ações executadas nas imagens que você está exibindo só ocorram quando for absolutamente necessário. Parece que uma operação cara está ocorrendo toda vez que você exibe as miniaturas, o que atrasa qualquer saída (incluindo os cabeçalhos) do script.

A maioria dos problemas lentos é que seu TTFB (tempo até o primeiro byte) está muito alto. É difícil resolver isso sem se intimidar com os arquivos de configuração do servidor, o código e o hardware subjacente, mas posso ver que isso é galopante em todas as solicitações. Você tem muitas barras verdes (ruins) e muito poucas barras azuis (boas). Você pode parar de otimizar um pouco a interface, pois acredito que você fez muito nessa área. Apesar do ditado de que " 80% a 90% do tempo de resposta do usuário final é gasto no front-end ", acredito que o seu esteja ocorrendo no back-end.

TTFB é material de back-end, material de servidor, pré-processamento antes da saída e handshake.

Cronometre sua execução de código para encontrar coisas lentas, como consultas lentas de banco de dados, tempo entrando e saindo de funções / métodos para encontrar funções lentas. Se você usa php, tente o Firephp . Às vezes, uma ou duas consultas lentas são executadas durante a inicialização ou inicialização, como extrair informações da sessão ou verificar a autenticação e o que não é. A otimização de consultas pode levar a alguns bons ganhos de desempenho. Às vezes, o código é executado usando php prepend ou spl autoload, para que funcionem em tudo. Outras vezes, pode ser um mal configurado apache conf e ajustes que salvam o dia.

Procure loops ineficientes. Procure chamadas de busca lenta de caches ou operações de E / S lentas causadas por unidades de disco com defeito ou alto uso de espaço em disco. Procure usos de memória e o que está sendo usado e onde. Execute um teste repetido de 10 páginas na Web, em uma única imagem ou arquivo, usando apenas a primeira visualização de diferentes locais do mundo e não o mesmo local. E leia seus logs de acesso e de erro, muitos desenvolvedores os ignoram e confiam apenas nos erros de saída da tela. Se o seu host da Web tiver suporte, peça ajuda, se eles talvez não pedam ajuda educadamente de qualquer maneira, não vai doer.

Você pode tentar a Pré-busca de DNS para combater os vários domínios e recursos, http://html5boilerplate.com/docs/DNS-Prefetching/

O servidor é um servidor bom / decente? Às vezes, um servidor melhor pode resolver muitos problemas. Sou fã da mentalidade ' hardware é barato, programadores são caros ', se você tiver a chance e o dinheiro atualizar um servidor. E / ou use uma CDN como maxcdn ou cloudflare ou similar.

Boa sorte!

(ps eu não trabalho para nenhuma dessas empresas. Além disso, o link do cloudflare acima argumentará que o TTFB não é tão importante, joguei isso lá para que você possa fazer outra tentativa.)

Lamento dizer, você fornece poucos dados. E você já teve algumas boas sugestões.

Como você está servindo essas imagens? Se você está transmitindo esses arquivos via PHP, está fazendo uma coisa muito ruim, mesmo que eles já sejam gerados.

NUNCA TRANSMITE IMAGENS COM PHP. Isso reduzirá a velocidade do servidor, não importa como você o use.

Coloque-os em uma pasta acessível, com um URI significativo. Em seguida, ligue diretamente para o URI real. Se você precisar de geração dinâmica, deve colocar um arquivo .htaccess no diretório images, que será redirecionado para um gerador de script php somente se a imagem solicitada estiver ausente. (isso é chamado de estratégia de cache sob solicitação).

Isso corrigirá a sessão php, o proxy do navegador, o cache, o ETAGS, o que for de uma só vez.

O WP-Supercache usa essa estratégia, se configurado corretamente.

Escrevi isso há algum tempo ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), as últimas revisões estão quebradas, mas acho que 8 ou menos devem funcionar e você pode pegue o arquivo .htaccess como exemplo apenas para testar as coisas (embora haja maneiras melhores de configurar o arquivo .htaccess do que antes).

Eu descrevi essa estratégia nesta postagem do blog ( http://www.stefanoforenza.com/need-for-cache/ ). Provavelmente está mal escrito, mas pode ajudar a esclarecer as coisas.

Leitura adicional: http://meta.wikimedia.org/wiki/404_handler_caching