Aceste informații sunt un extras pentru începători avansați. Lista de verificare pentru cele mai avansate este de aproximativ 60 de puncte.
Viteza site-ului este unul dintre parametrii cei mai importanți. Dacă site-ul se va încărca pentru o lungă perioadă de timp, atunci vizitatorul va părăsi pur și simplu site-ul fără a aștepta descărcarea. De asemenea, Google a început să acorde atenție vitezei descărcării site-ului și reduce poziția site-ului dacă este lentă.
În general, optimizarea perfectă perfectă necesită o abordare foarte serioasă și implică specialiști care se specializează în acest domeniu. Ei, timp de câteva zile, explorează blocajele site-ului și le repară. Dar există multe tehnici rapide și simple care vor ajuta să respire site-ul mult mai liber. Nu este necesar să aplicați toate tehnicile din lista de mai jos, să încercați fiecare dintre ele și să vedeți cum afectează viteza site-ului.
Există două instrumente răcoritoare pentru verificarea vitezei site-ului - YSlow și GTmetrix. Acestea trebuie să fie utilizate după fiecare modificare. Înregistrați parametrii cheie de măsurare (încărcarea paginii, mărimea paginii, numărul de cereri HTTP și evaluarea globală în puncte) înainte de fiecare modificare pentru a vă asigura că vă deplasați în direcția corectă. Puteți încerca, de asemenea, JMeter și Apache Bench.
kosHta a scris:
se concentrează pe programatori?
după ce am început să dezvolt celelalte degete în drupal, a început să devină mai ușor. Într-un sens, trebuie doar să luați și să faceți ceea ce aveți nevoie, în loc să citiți o grămadă de Internet, să instalați 2-3 module, să încercați să înțelegeți cum funcționează și de ce nu fac ceea ce doriți sau nu. Și judecând după felul în care a fost aranjat totul și numărul contramăsurilor - mi se pare că da, da, mai mult despre programatori.
deb scris:
Modul foarte ciudat. De ce depozitarea fișierelor este mai bună decât muskla? Selecția cheii primare a mouse-ului funcționează foarte repede. Pe scurt, beneficiile unui astfel de modul sunt extrem de îndoielnice.
MySQL are probleme de performanță după trafic de 20MB / s (în afara bazei de date)
VIEWS - generează acest trafic. Și cu cât mai multe vizionări și date aveți, cu atât mai mult trafic.
De fapt, se pare că cele mai multe ori sunt cheltuite pentru obținerea acestor date din baza de date, mai degrabă decât pe eșantionul lor.
Ca urmare, atunci când se transferă în cache-ul de fișiere, sarcina se duce la IO a sistemului disc, care este mai bine proiectat pentru astfel de încărcături.
De fapt, diferența se obține între "IO în rețea + IO în fișierul bazei de date" și "IO pe disc". Acest lucru vă permite să salvați performanța bazei de date pentru utilizarea dorită, în loc să stocați memoria cache.
Alternativ, puteți memora memoria cache în memcached, dar instalarea acesteia pe majoritatea gazde nu este disponibilă sau necesită anumite cunoștințe de la utilizator.
Din nou, memcached utilizează memoria pentru a stoca cache-ul. Este mai scump decât spațiul pe disc.
Este deja necesar să se analizeze un anumit proiect.
În timp ce folosiți filecache (cacherouter), rezultă instantaneu.
Folosind DH.Elastic ca un exemplu, costul de gazduire cade mult pentru client.
"MySQL are probleme de performanță după 20MB / s de trafic (în afara bazei de date)"
Nu este corect. Depinde de rețea, hardware, setări etc. Ie această frază, în realitate, reflectă un caz particular și nu este deloc asociată cu Mysql. El nu are o astfel de limitare arhitecturală. În cazul dvs. particular, nu funcționează în acest fel.
Este posibil ca IO în rețea să nu fie deloc, de exemplu, dacă serverul de baze de date se află pe același server, atunci când lucrați prin prize este foarte mică. Sau, cantitatea de latență a discului și a rețelei bazei de date poate fi mai mică decât întârzierea drive-ului cu fișierele, care nu pot fi de asemenea locale și, în plus, nu sunt rapide.
Sau întârzierile în rețea care încetinesc totul în jos cu un număr mare de cereri (și nu trafic, apropo, în primul rând) pot fi foarte mici.
Sau cache-ul sistemului de fișiere poate fi îndepărtat și va fi nebun să-l puneți acolo.
Sau, ca un caz special, a rămas puțină memorie în memoria cache a sistemului de fișiere.
Greutatea cazurilor când memoria cache din baza de date va fi mai bună, în cele din urmă.
Și dacă pe unele dintre găzduirea dvs. și tariful dvs. acest caz funcționează bine și vă permite să salvați, merită și scrie în descrierea acestui tarif, probabil, mai degrabă decât să prezinte ca cea mai bună opțiune pentru toate cazurile.
Rezumat despre acest lucru: Da, uneori, memoria cache a fișierelor este mai bună. În realitate, acest lucru nu este atât de des. Discul IO de pe cele mai multe site-uri web este o strangulare, mai ales pe VPS ieftin.
ttenz a scris:
Vizualizarea caching-ului este un lucru foarte interesant
Situația. O galerie cu un ecran infinit de vizualizare. Previzualizările dispar (de fiecare dată în locuri diferite) atunci când pagina este reîncărcată. Sprijinirea găzduirii recomandată pentru a permite memorarea în cache. Previzualile au început să dispară cu forța dublă. Ce sfat?
Nou pe forum
Conținutul site-ului este publicat pe termenii CreativeCommons Attribution-ShareAlike 3.0 sau o versiune ulterioară
Codurile programului din textul articolelor sunt GNU GPL v2 sau mai târziu.
Drupal este o marcă comercială a lui Drissa Bitaerta
Trimiteți-le prietenilor: