Activ (. Engl keep-alive) Compusul a fost un progres în HTTP 1.1 caietul de sarcini: este posibil să se utilizeze un canal deja stabilit pentru informațiile de retransmisie de la client la server și înapoi (în HTTP 1.0 conexiuni sunt închise imediat după transferul de informații server care adaugă o întârziere , asociat cu o transmitere în trei etape a pachetelor). În cazul în care problema resurselor libere este destul de acută, puteți lua în considerare stabilirea unui interval de timp limitat pentru astfel de conexiuni (5-10 secunde).
Cu toate acestea, HTTP 1.1 a adăugat dezvoltatorilor web o durere de cap într-o altă ocazie. Să înțelegem cum să eliminăm această problemă.
Costurile de livrare pentru obiecte
Pagina medie web conține mai mult de 50 de obiecte, iar costurile pentru numărul de obiecte domină toate celelalte întârzieri atunci când majoritatea paginilor web sunt încărcate. Browserele, care respectă recomandările specificației HTTP 1.1, nu stabilesc de obicei mai mult de două conexiuni simultane la o gazdă. Cu creșterea numărului HTTP- cerere, necesare pentru a face pagina, cu 3-23 - timpul necesar este de a „curate“ de descărcare obiecte scade de la 50% la doar 14% din timpul total de încărcare.
În cazul în care numărul de obiecte pe o pagină depășește 4, atunci costul de așteptare pentru fluxuri disponibile și parsa bucăți pentru obiectele trimise prevalează asupra timpului total de încărcare a paginii (de la 80% la 86% pentru 20 și 23+ obiecte, respectiv), comparativ cu timpul necesar pentru a încărcarea efectivă a datelor. Timpul de inițializare plus timpul de așteptare cauzat de restricția conexiunilor paralele ocupă 50-86% din timpul total de încărcare a paginii.
Atunci când numărul de obiecte conectate este mărit peste 10, timpul petrecut pentru inițializarea conexiunii crește până la 80% sau mai mult din timpul total necesar pentru recepționarea obiectelor. Este de remarcat faptul că puteți reduce semnificativ costul livrării unui număr mare de obiecte (mai mult de 12 pe pagină) prin includerea pentru server a unui mod de păstrare în viață și distribuirea de interogări mai multor gazde.
Restricții privind specificația HTTP / 1.1
Browserele au fost create în epoca în care un număr foarte mare de utilizatori au utilizat acces dial-up cu bandă redusă, deci a fost important să limitați utilizatorii la un număr mic de conexiuni simultane. Costul general al comutării între mai multe conexiuni cu acces dial-up a făcut foarte dificilă procesarea și descărcarea fiecărei solicitări individuale. Mai mult decât atât, în epoca de servere Web și proxy nu au fost suficient de puternice pentru a sprijini mai multe conexiuni, astfel încât o limită tare pe numărul de conexiuni concurente browser-ul a redus semnificativ riscul de cădere a infrastructurii de rețea în ansamblu.
- Dați obiectele de pe mai multe servere
- Creați mai multe subdomenii pentru mai multe gazde
Pentru a găsi un echilibru adecvat, IE până la versiunea 7 inclusiv limitează utilizatorii la doar opt conexiuni simultane sau două conexiuni la gazdă pentru protocolul HTTP 1.1. HTTP 1.0 este un pic diferit în această privință, dar aceasta este o altă poveste, deoarece toate beneficiile conexiunilor permanente sunt disponibile numai dacă folosim HTTP 1.1 (sau deja facem acest lucru).
Timpul se schimba
Firește, în lumea reală, toate aceste soluții utilitare au o particularitate de a deveni depășite, împreună cu timpul și mediul lor. Astăzi, cei mai mulți utilizatori au acces la Internet în bandă largă, astfel încât cea mai gâtuire nu mai este o parte de client (partea de client a fost, este și va fi cel mai gâtuire în performanța aplicației noastre de web, trebuie doar să înțeleagă modul în care se poate optimiza în fiecare caz) , iar lățimea de bandă a canalelor în majoritatea cazurilor.
În mod obișnuit, întârzierile în preluarea obiectelor individuale sunt semnificativ mai mari decât timpul pentru a stabili o nouă conexiune și a trimite solicitarea. Creșterea numărului de conexiuni concurente, putem paraleliza acest loc și mult mai rapid pentru a reduce printr-o varietate de obiecte care se află în lista de așteptare pentru a fi încărcate, care, la rândul său, la o creștere a vitezei percepută de încărcare a utilizatorului „la viteza fulgerului.“
Din păcate, pentru a se baza pe faptul că utilizatorii înșiși vor schimba setările browserului (și cum se poate face, vom vorbi despre capitolul opt) - aceasta nu va fi cea mai bună strategie pentru optimizare. Deci, ce face dezvoltatorul pentru a obține același efect din partea lui?
"Tăiați" conexiunile
Descărcarea cu două conexiuni Imaginile mici (de exemplu, articolele din magazin sau fotografiile pentru știri), în mod prestabilit, sunt descărcate de la gazda părinte, astfel că sunt obligate să utilizeze aceleași două conexiuni disponibile. Mai jos este o diagramă aproximativă a încărcării obiectelor pe pagină.
Fig. 23. Încărcarea imaginilor cu două conexiuni. Sursa: www.ajaxperformance.com
Acest grafic arată în mod clar că pentru musicstore.ajaxperformance.com deschis numai 2 Compusul (această diagramă este un model și este valabil numai pentru IE, în toate celelalte browsere, în mod implicit, oferă compuși mari): C0 și C2. Folosim protocolul HTTP 1.1, deci nu este nevoie să deschidem o conexiune separată pentru fiecare imagine, dar vom pierde încă o mulțime de timp pentru a satisface cererile individuale pentru obiecte. Timpul de stabilire a conexiunii (timpul până la primirea primului octet, bara albastră din diagramă) domină în mod clar timpul de încărcare a datelor, care nu este atât de mare (bara roșie a diagramei).
Desigur, puteți configura mai multe servere pentru a menține ieșirea imaginilor sau a altor obiecte pentru a crește numărul de descărcări paralele. De exemplu:
Încărcarea cu șase conexiuniimage3.yoursite.ru Cu toate acestea, fiecare dintre aceste subdomenii nu trebuie să fie pe un server separat.
Mai bine, mai mult, mai repede
Pentru a îmbunătăți performanța, puteți crea înregistrări CNAME în tabelul DNS pentru imagini1.yoursite.com, images2.yoursite.ru și images3.yoursite.com, fiecare dintre ele îndreptându-se către gazda principală.
La prima încărcare, performanța va fi mult mai bună. Așa cum se poate vedea din graficul de mai jos, acum există deja 6 conexiuni pentru încărcarea imaginilor noastre.
Fig. 24. Încărcare cu șase racorduri. Sursa: www.ajaxperformance.com
Câștiguri reale
Timpul de încărcare a paginii pentru utilizare a scăzut cu mai mult de 40%. Această tehnică va funcționa în toate cazurile atunci când aveți o mulțime mare de interogări pentru obiecte care se află pe același server.
Această abordare poate fi aplicată și pentru a izola fiecare parte din aplicația dvs.. În cazul în care unele elemente au nevoie de acces la baza de date și descărcarea acestora este întârziată mai mult pentru obiecte statice, este necesar pentru a le elimina din cei doi compuși care urmează să fie utilizate pentru a încărca imagini pe site-ul dvs., de exemplu, prin plasarea lor pe un subdomeniu.
Rezumă
Acum, pagina web medie este format din mai mult de 50 de obiecte (pentru Runet, conform statisticilor webo.in, situația este foarte asemănătoare: numărul de obiecte este în intervalul 40-50), prin urmare, reducerea la minimum costurile de livrare a obiectelor este foarte critică pentru performanța clientului. De asemenea, puteți reduce numărul de obiecte din pagină dacă utilizați tehnica CSS Sprite (sau date: URI) și combinați fișierele text pe server. Având în vedere că în momentul în care utilizatorii au un canal suficient de rapid, este posibil să se reducă timpul de descărcare la 40-60% (în funcție de numărul total de obiecte). Puteți utiliza 2 sau 3 gazde pentru a servi obiecte de pe un server pentru a "bloca" browserele în restricțiile lor privind încărcarea mai multor obiecte în paralel.
Trebuie reținut faptul că cererile simultane crescute vor implica utilizarea de resurse suplimentare pe partea serverului (acesta poate fi, de exemplu, numărul maxim de conexiuni sau porturi deschise și volume suplimentare de memorie RAM). Prin urmare, această abordare ar trebui utilizată în mod activ numai dacă există un server "ușor", capabil să suporte în același timp mii și zeci de mii de conexiuni deschise, fără a afecta performanțele (de exemplu, nginx sau 0W).
Merită să atingi încă un punct foarte interesant în optimizarea timpului de încărcare prin creșterea numărului de fire paralele. Aceasta constă în alinierea și mărirea dimensiunii obiectelor încărcate simultan pentru a utiliza în maximă conexiunile existente. De exemplu, dacă aveți 40 de fotografii de 5 KB, atunci este mult mai profitabil să dați 10 poze de 20 KB de la două gazde decât 20 (10 KB) de la 4 gazde sau 40 de la 8. Întârzierile generale în primul caz vor fi minime în forță pentru a maximiza viteza efectivă de descărcare a datelor către client.
Puteți merge mai departe și încărcați, de exemplu, 4 fotografii de 50 KB în 4 fluxuri, obținând doar o accelerare fenomenală. Cu toate acestea, factorul psihologic intră în joc aici: utilizatorul nu va fi confortabil dacă vede pagina în totalitate fără imagini tot timpul, în timp ce se încarcă 50 KB și el poate doar să părăsească site-ul.
Trimiteți-le prietenilor: