PHP flush: quantas vezes e Melhores Práticas

votos
23

Acabei de ler este post: https://developer.yahoo.com/performance/rules.html#flush e já implementaram um flush após a parte superior da minha página cargas (cabeça, css, Top Banner / search / NAV) .

Existe algum desempenho atingido em Flushing? Existe tal coisa como fazê-lo muitas vezes? quais são as melhores práticas?

Se eu estou indo para bater uma API externa para dados, faria sentido para lavar antes da mão de modo que o usuário não está à espera de que os dados de voltar, e pode, pelo menos, obter alguns dados antes da mão?

Publicado 09/12/2008 em 14:51
fonte usuário
Em outras línguas...                            


4 respostas

votos
19

A técnica descrita parece bom, mas tem várias armadilhas:

1) o tempo entre o início do roteiro PHP e final é pequeno em comparação com o tempo de transmissão; Também, isso poupa o usuário sobre 0,5 segundos, de acordo com sua fonte. É que uma quantidade significativa de tempo para você?

2) esta técnica não funciona com gzip o buffer de saída

3) se você lavar muitas vezes, você vai ser o envio de um pacote quase vazio em flush, o que pode realmente aumentar o tempo de carregamento (em, conexões ruidosos lentas).

4) uma vez que você lavar, você não pode enviar mais headers

5) (questão menor) a resposta do servidor virá a codificação fragmentada, o que significa que o cliente não vai saber o tamanho de antecedência (portanto, não irá exibir "x% feito" quando o download de um arquivo).

Por outro lado, se você espera que o seu script para ser executado por um tempo loooong (20 + segundos), pode ser necessário para enviar alguns dados (espaços, por exemplo) para manter o navegador do tempo limite da conexão.

Respondeu 09/12/2008 em 15:10
fonte usuário

votos
5

lado ruim é que você não pode gzip o conteúdo, bem como rubor-lo afaik, então eu sempre preferi gzip em vez de flush.

Algumas versões do Microsoft Internet Explorer só vai começar a exibir a página depois de terem recebido 256 bytes de saída, assim você pode precisar enviar espaço em branco antes de descarregar para os navegadores para exibir a página.

Isso faz com que isso não idéia, como parece estofo mais dados não é muito útil.

Respondeu 09/12/2008 em 14:58
fonte usuário

votos
3

Acho flush é realmente um mecanismo de ajuste fino. Navegadores usar apenas cerca de 8 threads para baixar conteúdo (depende do navegador). Se você tem 15 imagens, o navegador irá começar a baixar 8 imagens e não vai baixar qualquer outra coisa, até que um deles completa, então ele vai começar a baixar a próxima imagem, etc., através de lavagem após o cabeçalho, você está basicamente dizendo ao navegador o que ele pode iniciar o download. No momento em que o resto da página é entregue (ou seja .5 segundos depois), o navegador pode já ter terminado o download do CSS e JavaScript arquivos. Isso iria liberar tópicos para download de outros conteúdos.

Você provavelmente não quer usar nivelado em qualquer outro lugar do que logo após o cabeçalho. Um navegador normalmente não irá processar tags HTML não fechadas, de modo entregar uma página parcial não exibirá as coisas qualquer mais rápido. versões mais antigas do IE não exibirá nada até que uma certa quantidade de dados é recebido, ou envio página está completa.

Respondeu 30/03/2010 em 14:11
fonte usuário

votos
2

Após o ponto de Piskvor - se você está esperando um 20s + esperar, você pode ser melhor para fornecer uma página básica (que pode ser compactado) e usando Ajax para atualizar a página quando o lento processo tenha terminado. Você começa a infringir a utilidade básica de HTML estático, no entanto.

Respondeu 09/12/2008 em 15:17
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more