Reducerea timpului de răspuns server - cum să rezolve problema

Recent, am descris procesul de optimizare a script-uri și stiluri de pe site-urile lor, totul a iesit bine, dar o mare problemă rămâne - Reduce timpul de răspuns server. Am scris un bun Google.

Într-adevăr, întârzierea înainte de a descărca site-ul meu despre Linux este foarte mare, mult mai mare decât toate celelalte site-uri web de mai multe ori, și asta e prea rău!

Să vedem ce starea site-ului în acest moment:

26 - astfel încât multe interogări SQL la baza de date.
1.205022 - pentru atât de multe pagini generate.

Aceasta este pagina principala a unui site despre Linux. Acum am verifica în același mod pagina principală a acestui site:

34 - astfel încât multe interogări SQL la baza de date.
0.351147 - pentru atât de multe pagini generate.

După cum puteți vedea, interogarea bazei de date este mai mare și viteza de generare a paginii este de patru ori mai mici. În acest caz, ambele site-uri de pe un singur server. sunt practic aceleași plug-in-uri, deși baza de date de pe acest site un pic mai puțin, dar toate bazele de date sunt optimizate și toate gunoi eliminate.
Toate acestea conduc la ideea că serverul în sine nu este de vina, în caz contrar toate site-urile ar fi inhibat aproximativ la fel. Deci, motivul poate fi după cum urmează:

1. Există un plugin curbă, care inhibă generarea paginii.

2. șablon Curve și orice greșeli în structura împiedicat funcționarea normală.

4. Erori în baza de date, iar datele sunt citite pentru o lungă perioadă de timp.

Nu știu ce altceva să sugereze, începe cu asta, voi pas cu pas pentru a testa teoriile si uita-te la rezultatul.

1. Cum se calculeaza plugin-ul curba?

Totul este simplu: În primul rând ne-am tăiat în jos, la o dată toate plugin-urile si uita-te la rezultatul:
15 - astfel încât multe interogări SQL la baza de date.
0.937074 - pentru atât de multe pagini generate.
După cum puteți vedea, nu de mult sa schimbat, ceea ce înseamnă că plugin-uri face cu ea. Această teorie este verificată, merge mai departe.

2. Cum de a verifica șablon WordPress?

Aici primul act, în același mod, încărcați unele șablon liber, introduceți-l în codul nostru și uita-te la rezultatul.
27 - astfel încât multe interogări SQL la baza de date.
1.170909 - pentru atât de multe pagini generate.
MDA, rezultatul este același, astfel încât tema nu este cu ea, trebuie să sape în continuare.

3. Cum pentru a verifica site-ul pentru a detecta viruși?

Ceva mă îndoiesc că aceasta este problema, puteți verifica site-ul antivirus Aibolit. N-am făcut un astfel de test. Dar toate acestea se va lua o lungă perioadă de timp. Cu toate acestea, sunt înclinat să cred că problema este în baza de date, ca atunci când descărcarea unui site accesat în primul rând la ea.

4. Cum pot verifica baza de date?

Mi-a luat o zi înainte am rezolvat problema. Vreau doar să arate rezultatul:

29 - astfel încât multe interogări SQL la baza de date.
0.168516 - pentru atât de multe pagini generate.

Vezi diferenta? 1,2 secunde sau 0.16 secunde? Această diferență este de zece ori. Cum am reușit să realizeze acest lucru?

Primul lucru pe care am făcut a fost sortat tabelul bazei de date pentru a vedea ce ocupă cel mai mult spațiu. I a lua acest lucru:

Cel mai mare, și, prin urmare, starneste suspiciunea au fost 4 mese, în ordine descrescătoare:

La început, am luat masa POSTMETA și curățat din ea un pic de gunoi, cea mai mare parte cache, care a lăsat un plugin. Dar toate acestea nu a ajutat. Apoi am luat opțiunile de masă.

Am instalat plugin-ul Clean Options (doar plugin creat pentru a curăța acest tabel), care mi-a găsit mai mult de o mie de opțiuni rămași orfani! Am șters aproximativ 700 de rânduri inutile din tabel, stânga 300, care pare inutil.

Dar nu a ajutat, cu toate că această operație este necesară. Am fost oripilat de faptul că toate plugin-urile lăsa în urmă atât de mult gunoi. Acest lucru mi-a dat ideea nu este de a pune mai multe plugin-uri pe blog-ul principal, dacă nu sunt convins că am nevoie de ea. Puteți crea un site de test pe un subdomeniu și tren pe ea.

Vinovatul a fost în jurul valorii de cron. Dacă nu știi ce este, aici pentru referință:

cron - daemon Task Scheduler în sistemele de operare UNIX, cum ar fi, este utilizat pentru a efectua periodic sarcini, la un anumit interval de timp.

Nu am plănuit nimic și nici măcar nu știu ce este un plugin creat atât de multe locuri de muncă! Am intrat și am găsit phpMyAdmin în acest tabel această secțiune, am șters-o fără milă Venture! Tabelul a scăzut de la 3,5 MB la 168 kilobytes. După aceea, site-ul a început să zboare salbatic!

Eu nu folosesc sarcinile programate, iar acum mă voi gândi la cum să dezactivați cron pentru totdeauna, sau după un timp el ar putea din nou, am murdărit baza de date cu un mod monstruos.

Dacă știi de ce am toate astea sa întâmplat și cum să-l evite pe viitor, dispus să asculte sfatul unui specialist. Dar, în general, eu sunt foarte fericit pentru că ziua în care am avut gândit doar despre asta. Rămâne doar să-l facă totul pe alte site-uri, și dintr-o dată există această problemă, deși nu pe o astfel de scară? Și, în cele din urmă lăuda plug-cache este dezactivat:

1.7 secunde - se pare a fi cool?

Cum de a găsi resturile de plug-in-uri?

Cu toate acestea, am găsit un plugin interesant - Plugins gunoier. El scanează baza de date și caută tabele care nu aparțin WordPress:

Am găsit un tabel care nu este utilizat deja de plugin-uri, așa că le-am șters - în cuptor! Deci, de asemenea, poate fi un pic mai clară a bazei de date moloz.

Cum de a reduce timpul de răspuns de la server?

Toate acestea m-au ajutat foarte mult pentru a accelera site-ul, dar încă Google Speed ​​semnalat pentru mine că timpul de răspuns este foarte mult pe server. Iar vina pentru acest lucru nu serverul în sine, ca documente HTML simple sunt încărcate fără întârzieri, și WordPress motor de site-ul care nu accelerează ca o racheta nu va. Ce să fac?

Problema a fost rezolvată cu ușurință - instalarea plugin-ul site-ului pentru cache. Dar nu totul a fost atât de simplu într-adevăr, pentru că nu toate plug-in-uri pentru paginile de cache a lucrat așa cum ar trebui.

Unul nu a lucrat deloc, deși cache-ul creat. Dar dacă unii au făcut în acest sens, bine, a existat o altă problemă - versiunea mobilă a site-ului. În cazul în care cache-plug-in este nici o deosebire între mobil și memoria cache convențională, vă confruntați cu o astfel de problemă.

Dintre toate plug-in-uri, care au separarea între un telefon mobil și o memorie cache convențională, am găsit doar un singur - CACHE HYPER.

În această filă, trebuie să setați setările de aici, astfel încât versiunea mobilă a site-ului din cache separat. După aceea, problema timpului de răspuns de la server a dispărut.

Până la 100/100 în Google Speed ​​am lăsat destul de un pic și eu sunt sigur că voi obține acest rezultat, pentru că aproape totul a fost făcut, există foarte puține.

Îmi place de joc? Ia-COD. a pus pe site-ul dvs. și de a îmbunătăți factorii de comportament!

Vă mulțumesc pentru sfaturi, asigurați-vă că pentru a încerca, pentru că problema de viteză pe 100% nu au decis încă.

Și am realizat un lucru important: este imposibil de a testa plug-in-uri de pe site-ul principal, după scoaterea lor este întotdeauna o mulțime de gunoi, uneori megaocteți. Oroarea!

Dar, din păcate, Google viteza de pagină și nu-mi place timpul de răspuns de la server. Am decis să scrie o gazdă și a primit de la el acest răspuns:

Pot să spun că performanța de site-ul dvs. este destul de mare. Google în sine pentru serviciile sale oferă rezultate aproape egale pentru site-ul tau. Deci, este foarte, foarte bun.

Voi adăuga că acest serviciu este un pic de paranoia în raport cu viteza de site-uri web. N-ar avea 100% încredere în el.

Ei bine. cred până la cuvântul, celelalte opțiuni nu știu, trebuie să verificați site-urile altor oameni pe noi WordPress, cum sunt ei?