Astăzi vreau să vorbesc despre modul de reducere a încărcării pe serverul gazdă. create de blogul dvs. pe WordPress. Recent, un furnizor de gazduire mi-a trimis o scrisoare de avertisment spunand ca blogul meu creeaza o sarcina pe server peste limita stabilita pentru tariful meu. Mai mult, a fost al doilea avertisment și, prin urmare, fără a aștepta a treia, am început să găsesc căi de a reduce încărcarea pe server pe care site-ul meu o creează.
WordPress lăcomia
După cum sa dovedit, că site-ul WordPress a început să creeze o povară inacceptabilă pe CPU serverul, nu au nevoie de mult: doar 15-20 de ori într-un rând (cu o pauză de mai puțin de 0,75 secunde), faceți clic pe același link, sau pur și simplu deschis cu o viteză maximă de 15 20 de pagini ale site-ului în file sau ponazhimat F5 în browser de zeci de ori.
În cazul în care un furnizor de sarcină inacceptabil solicită 5%, astfel că e ceva Făcând clic simplu, dacă încercați într-adevăr, puteți apela sarcina, in functie de busteni, până la 28 la sută (.). Și acum imaginați-vă că nu a fost un utilizator care a făcut clic, dar doi? Da, problema este relevantă doar pentru găzduirea virtuală și chiar și atunci există gânduri despre cum ar putea să o optimizeze. Cu toate acestea, problema există.
De asemenea, a devenit clar faptul că fiecare nouă versiune a WP devine mai lacomă. De exemplu, dacă versiunea 2.3.3 a consumat mai puțin de 10 MB de memorie, atunci 2.7.1 - cel puțin 20.
Practica arată că site-ul meu cu o grămadă de widget-uri consumă uneori până la 45-55% din timpul procesorului. De unde provin aceste numere?
Imaginile, stilurile și scripturile sunt "conținut static". Nu se schimbă în timp și astfel de apeluri au nevoie de resursele cele mai reduse (timpul CPU nu este practic utilizat, memoria necesită o sumă minimă). Cu toate acestea, dacă pentru tine pe un site cu materiale exclusiv statice 100 mii de oameni pe zi va veni, încărcătura el va crea încă decent. Dar în cazul nostru principala problemă este "conținutul dinamic".
De exemplu, pentru un afișaj al unei pagini, WordPress 2.8 cheltuiește aproximativ 19 MB de memorie și o secundă de timp. Aceasta înseamnă că, în decurs de o secundă, pentru toți ceilalți clienți ai dvs. de găzduire nu este disponibilă aproximativ 25 megabytes de memorie. Să presupunem că aveți 100 de vizitatori pe zi și în medie au 3 vizualizări ale paginii. Deci, site-ul dvs. petrece undeva 300 * 25 MB de memorie pentru 300 de secunde. Pe o scară zilnică, totul este bine.
Dar să presupunem că site-ul începe să crească participarea (până la 150 de persoane pe zi), sau ați instalat unele plug-in nou super-Duper, WordPress și consumul de memorie a crescut la 30 MB. Astfel, consumul de resurse al hostelui a crescut cu aproximativ 50%. În cazul în care compania de găzduire consideră că sunt consumatoare de prea mult timp de memorie și CPU pentru banii pe care îl plătiți pentru asta - va fi trimis un avertisment cu privire la o posibila dezactivarea a site-ului și propunerea de a schimba planul tarifar.
Deci, conținutul dinamic este o cerere suplimentară către baza de date și timpul procesorului. Și, cu atât mai mult în codul șablonului de interogare la baza de date, cu atât mai mult va fi sarcina. De fapt, fiecare add-on plug-in și widget, care pentru munca lor selectați ceva din baza de date, creează o sarcină suplimentară.
Alte motive pentru încărcarea grea a procesorului pot fi atacurile DDoS și munca roboților de căutare. Dat fiind faptul că pot deschide o mulțime de pagini la rând sau, în general, în același timp, dar nu pot fi alungate, pentru că unde altundeva fără ele, atunci pot apărea din nou probleme cu gazda.
Principalele cauze ale supraîncărcării
Principalele motive pentru care blogul este foarte încărcat:
Metode de combatere a încărcăturii
În primul rând, trebuie să aflați ce sa întâmplat recent. Poate că site-ul a crescut în popularitate. Poate că site-ul a fost recent actualizat (se instalează o nouă versiune de WordPress). Poate că ați adăugat o pagină nouă sau ați instalat un plugin nou. Poate că lista de prețuri sa dublat?
Adesea, problema poate fi rezolvată prin activarea memoriei cache. De exemplu, pentru WordPress, acesta poate fi un plugin WP-SuperCache. În ModX, puteți plasa caseta de validare "document cached" în paginile corecte. În Drupal, acest lucru se face în meniul "Site Setup -> Performance". Pentru Joomla puteți descărca PageCache.
Plugin-uri Caching pentru WordPress: Aceasta este WP-Cache, WP Super Cache, Hyper Cache, WP File Cache.
WP Super Cache este un plug-in static de cache pentru WordPress. Acesta generează fișiere HTML care sunt deservite direct de Apache fără a procesa scripturi PHP relativ grele. Cu acest plugin puteți accelera în mod semnificativ blogul dvs. WordPress.
Principiul de funcționare este aproape identic cu WP Super Cache. De asemenea, crearea de pagini statice, stocarea lor și livrarea acestora la accesarea site-ului.
- de asemenea, o mulțime de memorie sub paginile cache-ului;
- manipularea neașteptată a paginii 404 și stabilirea cache-ului;
- se consideră că performanța sa cu multiple fire și cereri este mai mică decât cea a Super Cache.
Acesta este pluginul care mi-a plăcut și pe care vă pot recomanda. Prin urmare, în privința lui, mai multe despre avantajele. Și acestea sunt următoarele:
Scurte concluzii: pe un server bine reglat, WP Super Cache conduce, atât în ceea ce privește viteza cât și sarcina.
Recent, a fost descoperit un alt plug-in care funcționează diferit decât cache-urile obișnuite.
Cache-ul DB Cache Reloaded plug-in este un instrument care oferă cache-ul dinamic al interogărilor bazei de date. Lucrările acestui plugin se bazează pe complet diferite, diferite de caching-ul static, plug-in-uri, principii și vă permite să creșteți în mod semnificativ viteza de încărcare a blogului și să reduceți sarcina de găzduire.
De fiecare dată când este generată o pagină de blog, există interogări către baza de date trimisă de temă, widget-uri, pluginuri. DB Cache Reloaded cache aceste cereri, le trimite mai târziu nu la baza de date, ci la cache, accesul la care este mai rapid. Prin urmare, numărul de apeluri către baza de date este redus de mai multe ori (în cazul meu, de la 25 la 5). Acest lucru reduce încărcarea CPU-ului și utilizarea RAM - reduce sarcina globală a găzduirii, reduce timpul pentru generarea de pagini de blog. Setările plug-in-ului sunt minime, există un cod care poate fi introdus în footer.php pentru a afișa timpul de încărcare a blogului, numărul de accesări la baza de date și cantitatea de memorie consumată.
Dacă nu se face caching simplu - aveți nevoie de un aspect profesional. Este necesar să găsiți un plug-in sau un modul "rău" și să îl actualizați, reparați sau înlocuiți. Cu privire la viclean - vă pot recomanda dezactivarea modulelor de statistici și, în schimb, utilizați contorul LiveInternet sau Google Analytics. Optimizarea optimă a site-ului poate dura o cantitate mare de timp (și bani), deci rezolvați problemele pe măsură ce apar.
Blocați cererile pentru versiuni noi
Motorul WordPress este proiectat astfel încât, de fiecare dată când intră în partea administrativă, se va vedea dacă orice plugin a fost actualizat. Cum o face el? Fiecare plugin are o pagină proprie, de obicei este o secțiune în directorul de pluginuri de pe wordpress.org. Când te duci acolo, el compară versiunea instalată în tine cu cea care se află pe site-ul plug-in-ului. Dacă există unul mai nou, atunci acesta oferă actualizarea pluginului.
Același lucru face și în legătură cu el însuși - de fiecare dată când verifică dacă dezvoltatorii WordPress au făcut o nouă versiune. Este clar că o astfel de lucrare mănâncă departe de site-ul dvs. și astfel cele câteva megabyte de memorie care sunt alocate de către furnizor pentru funcționarea sa.
Nu sunt utilizate pentru a actualiza în mod frecvent plugin-uri, și odată ce le-a luat și setare, prefer să nu mai deranjez cu ei, profesând principiul „muncii - nu atinge“. Prin urmare, este suficient să verific trei sau patru ori pe an dacă a ieșit o nouă versiune a unui plug-in, dar pentru restul timpului, dezactivați această funcție.
Am făcut asta cu mâinile mele, corectând fișierul de configurare. Acest lucru a continuat până când Kalinin nu a făcut un plug-in, care, în zbor, îi lipsește pe WordPress să verifice actualizările plug-in. În același timp, dezactivează WordPress în sine de la verificarea actualizărilor. Acest plug-in se numește Blocarea cererilor pentru versiuni noi. Pluginul funcționează pur și simplu: activat - funcționează, nu este activat - nu funcționează.
Verificarea automată a versiunilor (revizuiri)
După editarea oricărei postări, WordPress va salva versiunea anterioară, astfel încât, în caz de orice, puteți să vă răsturnați. Dar ghinionul este "în cazul a ceea ce" se întâmplă foarte rar și, de fapt, toate aceste duplicate ale versiunilor anterioare ale postului meu nu sunt necesare. WordPress face astfel de copii de siguranță periodic, și toate se acumulează și se acumulează. Există un spațiu pentru ei, iar motorul este într-o stare de monitorizare constantă și de rezervă. Cred că nu am nevoie de ea, așa că am deconectați această posibilitate (recunosc, pentru cineva poate util), și, împreună cu spațiu liber pe un server și reduce sarcina motorului prin reducerea bazei de date.
După instalare, plug-in-ul va afișa posturile care au versiuni. Cred că nu aveți nevoie de ele de mult timp, le puteți șterge. După aceea, ar fi drăguț să indicați dacă ar trebui să faceți chiar o astfel de revizuire a posturilor și, dacă da, atunci cât de des și în ce cantitate. În general, am curățat totul.
Acest plugin, așa cum am spus deja, vă permite să nu aglomerați baza de date cu informații excesive și cu cât baza de date este mai mică - cu cât WordPress funcționează mai repede.
Ambele pluginuri sunt bune în primul rând prin faptul că nu trebuie să accesați cu crawlere codul și să îl editați manual. În plus, dezactivarea plug-in-urilor duce la restabilirea setărilor implicite. Acestea nu sunt singurele moduri de a accelera WordPress, dar ele sunt cele mai accesibile.
WP-Optimize plugin
Știți că atunci când ștergeți mesaje spam, acestea nu sunt șterse din baza de date, dar sunt pur și simplu ascunse de ochi? Nu știu de ce dezvoltatorii WordPress au venit cu asta, dar personal nu am nevoie de această colecție de chestii invizibile. Deși nu o văd, dar se află în baza de date. Aveți nevoie de o revizuire a postărilor?
Pluginul poate șterge toate mesajele spammer, toate mesajele neconfirmate, optimizează baza de date, scapă de date inutile și schimbă rapid datele de conectare ale utilizatorilor cu un singur clic. La optimizarea tabelelor, rezultatul va fi afișat.
Analiza "curburii" site-ului dvs.
Pentru a verifica câte interogări are loc în baza de date atunci când descărcați o anumită pagină a site-ului dvs., puteți utiliza binecunoscutul plugin WP Tuner - descărcați pluginul WP Tuner. Pluginul este instalat în mod standard, și anume:
- dezarhivați arhiva wptuner.zip, utilizați managerul ftp pentru a vă conecta la site-ul dvs. și descărcați folderul wptuner în folderul wp-content / plugins / plugins de pe server
- introduceți zona de administrare wordpress și selectați fila "Pluginuri" - "Inactive"
- Găsiți linia cu pluginul WP Tuner și activați-l
- După activare, WP Tuner ar trebui să înregistreze setările în wp-config.php. Pentru a face acest lucru, deschideți temporar acest zail pentru o înregistrare cu drepturile 666 sau înregistrați manual o bucată mică de cod.
- Dacă codul nu este înregistrat de mașina automată, plugin-ul însuși va spune despre el în forma unei erori și a descrierii sale.
Acum puteți accesa zona de administrare a blogului dvs. și puteți vedea setările pluginului WP Tuner. În panoul de administrare selectați din meniul din stânga Setări -> Tuner WP.
De fapt, setarea nu este prea mult, în plus față de plug-in a început să arate numărul de cereri la baza de date la pagina de blog de pornire, în general, nu sunt necesare modificări. Pur și simplu accesați site-ul de la panoul de administrare (acest lucru este necesar pentru a se asigura că sunteți pe site-ul au fost sub conectare de administrator) și deschide orice pagină a site-ului. După descărcare, derulați în jos și veți vedea fereastra WP Tuner sub subsolul site-ului dvs. Figura de mai jos arată unde puteți vedea numărul interogărilor de bază de date care au fost făcute atunci când pagina a fost încărcată.
Vizitatorii obișnuiți la site, desigur, nu vor vedea această rușine, ci doar administratorul blogului, adică Mulțumesc.
Dar puteți examina numărul de interogări în baza de date fără a recurge la serviciile de plug-in-uri. Pentru a face acest lucru, trebuie să accesați fișierele site-ului dvs. prin FTP și să le deschideți pentru a le edita. de exemplu, fișierul /wp-content/themes/nazvanie_vashey_temy_oformleniya/footer.php, și undeva în codul de fișier pentru a insera următoarea structură (punctul de inserare va determina locația numărul de interogări din subsol sau de ieșire în mod diferit - subsolul blogului dvs.):
Ca rezultat, după încărcarea paginii site-ului dvs., în partea de jos a paginii veți vedea câte interogări au fost făcute către baza de date.
Aceste informații vor fi disponibile numai pentru utilizatorii conectați la blog. Ie Dacă ați dezactivat înregistrarea pe blogul dvs., numai acest mesaj va apărea.
În ceea ce privește optimizarea șabloanelor pentru a reduce numărul de cereri către baza de date, vom vorbi într-un articol separat.
Împărtășește în social. crearea de rețele
Articole similare
Trimiteți-le prietenilor: