PHP Flush: cât de des și cele mai bune practici

voturi
23

Tocmai am terminat de citit acest post: https://developer.yahoo.com/performance/rules.html#flush și au implementat deja o culoare după partea de sus a sarcinilor mele pagina (cap, css, banner sus / search / nav) .

Există vreo performanță lovit în spălare? Există un astfel de lucru ca o fac prea des? Care sunt cele mai bune practici?

Dacă am de gând să lovit un API extern pentru date, ar avea sens pentru a spăla înainte de mână, astfel încât utilizatorul nu așteaptă pe datele să vină înapoi, și pot obține cel puțin unele date înainte de mână?

Întrebat 09/12/2008 la 14:51
sursa de către utilizator
În alte limbi...                            


4 răspunsuri

voturi
19

Tehnica descrisă pare frumos, dar are mai multe capcane:

1) timpul dintre pornire script PHP și final este mic în comparație cu timpul de transmisie; De asemenea, acest lucru salvează utilizatorul aproximativ 0,5 secunde, în funcție de sursa. Este că o cantitate semnificativă de timp pentru tine?

2) această tehnică nu funcționează cu gzip ieșire tampon

3) în cazul în care vă spălați prea des, va trimite un pachet de aproape-gol de pe același nivel, care ar putea creste de fapt, timpul de încărcare (pe conexiuni lente, zgomotoase).

4) o dată ce spălați, nu puteți trimite nici mai multe antete

5) (problemă minoră), răspunsul serverului va veni în codare chunked, ceea ce înseamnă că clientul nu va cunoaște dimensiunea în avans (prin urmare, nu se va afișa „x% făcut“ atunci când descărcarea unui fișier).

Pe de altă parte, dacă vă așteptați să executați scriptul pentru un timp loooong (20+ secunde), poate fi necesară pentru a trimite date (spații, de exemplu) pentru a menține browser-ul de sincronizare legătura.

Publicat 09/12/2008 la 15:10
sursa de către utilizator

voturi
5

Partea de jos este că nu vă puteți gzip conținutul precum și aruncându-l AFAIK, așa că întotdeauna am preferat să gzip, mai degrabă decât la același nivel.

Unele versiuni ale Microsoft Internet Explorer va începe numai pentru a afișa pagina după ce au primit 256 bytes de ieșire, astfel încât este posibil să trebuiască să trimită spațiu gol suplimentar înainte de spălare pentru a obține aceste browsere pentru a afișa pagina.

Acest lucru face ca acest lucru nu idee, așa cum se pare că padding mai multe date nu este foarte util.

Publicat 09/12/2008 la 14:58
sursa de către utilizator

voturi
3

Cred că la același nivel este într-adevăr un mecanism de reglaj fin. Browserele utilizează doar aproximativ 8 fire pentru a descărca conținut (depinde de browser). Dacă aveți 15 de imagini, browser-ul va începe descărcarea 8 imagini și nu va descărca nimic altceva până când unul dintre ei se încheie, atunci acesta va începe să se descarce următoarea imagine, etc. Prin înroșirea feței după antet, vi se spune în esență browser-ul ce ea poate începe descărcarea. Până în momentul în care restul paginii este livrat (adică .5 secunde mai târziu), browser-ul poate fi terminat deja descărcarea css și fișiere JavaScript. Acest lucru ar elibera fire de descărcare pentru alte tipuri de conținut.

Probabil că nu doriți să utilizați la același nivel, în orice alt loc decât imediat după antetul. Un browser, de obicei, nu va face tag-uri html neinchise, astfel oferind o pagină parțială nu va afișa lucrurile mai repede. Versiunile mai vechi ale IE nu va afișa nimic până când se primește o anumită cantitate de date, sau de livrare pagină este completă.

Publicat 30/03/2010 la 14:11
sursa de către utilizator

voturi
2

Ca urmare punctul Piskvor lui - dacă așteptați un 20s + așteptați, s-ar putea fi mai bine oferind o pagină de bază (care poate fi garhivate) și folosind Ajax pentru a actualiza pagina atunci când procesul lent a terminat. Tu începe să încalce utilitatea de bază a HTML statice, totuși.

Publicat 09/12/2008 la 15:17
sursa de către utilizator

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