PHP Flush: Hoe vaak en Best Practices

stemmen
23

Ik ben net klaar met het lezen van deze post: https://developer.yahoo.com/performance/rules.html#flush en hebben al een flush na het bovenste gedeelte van mijn pagina wordt geladen (hoofd, css, top banner / search / nav) geïmplementeerd .

Is er een prestatie hit in Flushing? Bestaat er zoiets als het doet te vaak? Wat zijn de best practices?

Als ik ga naar een externe API voor data te raken, zou het zinvol zijn om te spoelen voor de hand, zodat de gebruiker niet zit te wachten op die data om terug te komen, en kan op zijn minst een aantal gegevens voor de hand?

De vraag is gesteld op 09/12/2008 om 14:51
bron van user
In andere talen...                            


4 antwoorden

stemmen
19

De beschreven techniek ziet er mooi uit, maar heeft een aantal valkuilen:

1) de tijd tussen PHP-script start en het einde is klein in vergelijking met de zendtijd; Ook, dit bespaart de gebruiker ongeveer 0,5 seconden, afhankelijk van uw bron. Is dat een aanzienlijke hoeveelheid tijd voor u?

2) deze techniek werkt niet met gzip uitgang buffering

3) als je te vaak te spoelen, wordt u het verzenden van een bijna lege packet op flush, die eigenlijk zou kunnen toenemen laadtijd (op langzame, luidruchtige verbindingen).

4) als je eenmaal te spoelen, kun je niet meer headers te sturen

5) (klein probleem) de server reactie zal komen in gedeelde codering, wat betekent dat de klant zal de omvang van tevoren niet weten (en dus niet weergegeven "x% done" bij het downloaden van een bestand).

Aan de andere kant, als u verwacht dat uw script te lopen voor een erg lang (meer dan 20 seconden), kan het nodig zijn om een ​​aantal gegevens te verzenden (ruimten, bijvoorbeeld) naar de browser van een time-out van de verbinding te houden.

antwoordde op 09/12/2008 om 15:10
bron van user

stemmen
5

Keerzijde is dat u de inhoud niet zo goed kan gzip als afaik te spoelen, dus ik heb altijd de voorkeur aan in plaats van gzip dan flush.

Sommige versies van Microsoft Internet Explorer zal alleen beginnen om de pagina weer te geven nadat ze 256 bytes van de output hebben ontvangen, dus je kan nodig zijn om extra witruimte sturen voordat het doorspoelen te krijgen die browsers om de pagina weer te geven.

Dit maakt dit niet idee, als het lijkt padding meer data is niet erg handig.

antwoordde op 09/12/2008 om 14:58
bron van user

stemmen
3

Ik denk dat flush is echt een fine tuning mechanisme. Browsers gebruiken slechts ongeveer 8 threads om content te downloaden (afhankelijk van de browser). Als u 15 afbeeldingen, zal de browser te downloaden 8 afbeeldingen en zal niet iets anders te downloaden totdat een van hen is voltooid, dan zal het beginnen met het downloaden van de volgende afbeelding, enz. Door het spoelen na de header, je bent in principe de browser te vertellen wat kan het downloaden te starten. Tegen de tijd dat de rest van de pagina wordt geleverd (dat wil zeggen 0,5 seconden later) kan de browser al klaar zijn met het downloaden van de css en javascript bestanden. Dit zou vrij te downloaden draden voor andere inhoud.

U heeft waarschijnlijk niet wilt flush te gebruiken in een andere plaats dan direct na de header. Een browser meestal niet maken ongesloten HTML-tags, zodat het leveren van een deel van de pagina zal geen sneller dingen niet weer te geven. Oudere versies van IE zal niets weer helemaal tot een bepaalde hoeveelheid data wordt ontvangen, of pagina levering compleet is.

antwoordde op 30/03/2010 om 14:11
bron van user

stemmen
2

Na punt Piskvor's - als u verwacht een jaren '20 + wachten, kunt u beter af het verstrekken van een basis pagina (die kan worden gzipped) en met behulp van Ajax naar de pagina bij te werken wanneer de langzaam proces is voltooid zijn. U moet beginnen met de fundamentele nut van statische html inbreuk, dat wel.

antwoordde op 09/12/2008 om 15:17
bron van user

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