Lent după golirea memoriei cache site-ului

[tavenger5]

Am trecut prin şi puse în aplicare toate trucurile posibile de optimizare pot găsi. Aceasta include nginx ca un proxy pentru Apache, vbOptimize cu memcached, şi toate procedurile obişnuite de optimizare vbulletin.

Lucrez cu două servere dublu procesor quad core cu 12 şi *** de berbec, şi unităţi SAS 15K în raid. Deci, cu alte cuvinte, serverele au suficienta putere pentru a procesa totul.

Site-ul principal incepe sa incetineasca imediat după cache vBET este ştearsă la fiecare 15 zile. (Baza de date ajunge la peste *** după această perioadă de 15 zile)> 500k de pagini pe zi sunt cu crawlere de către motoarele de căutare.

Este ceva ce pot face pentru a optimiza Apache pentru a se ocupă de aceste cereri mai bine? Acestea sunt setările mele curente Apache:
de la httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000
Din httpd-default.conf:

Timeout 150
Pe Keepalive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Lasă-mă să ghicesc - ai vBSEO şi mulţime de link-uri pe pagina principală - am dreptate? ;)

Trucul este - dacă nu aveţi cu adevărat, atunci nu utilizaţi strategie de compensare trecut. Ştiu că există în cazul în care - ai verificat alte strategii de compensare? Alte nu se va şterge memoria cache ansamblul său şi va lua mai multe resurse pentru a elimina de la partea cealaltă.

Înainte de presă vBET 3.x vă poate ajuta - vom adăuga noi parametri de performanţă avansate pentru paginile cu adevărat mari. Am descoperit, de asemenea, strangulare cu link-uri de traducere. In acest moment avem implementat solutia pentru URL-uri prietenoase vB în vBET4.x (nu a lansat încă) şi vom încerca să-l adopte, de asemenea, pentru vBSEO. Dacă vom reuşi, vom muta de asemenea, să vBET 3.x Problema este că vBSEO cere link-uri, unul câte unul şi aceasta produce zeci de cereri de Google. Dupa cum am scris le-am implementat deja soluţie vB adresele URL Frinedly - am facut traducere întârziat. Problema cu vBSEO este că lucrează în afara vB, după obţinute se întâmplă şi, de asemenea, nu spun nu are nevoie de url-ul pentru a verifica corectitudinea una reală
sau să-l pună în ieşire.
Lot de detalii - la scurt timp ştim o strangulare ceea ce se întâmplă numai atunci când cache-ul nu este completat, iar noi suntem deja lucrează la acest aspect.

Deci, la acest moment Pot recomanda doar sa va jucati cu strategii de compensare şi a altor parametri de compensare. Pentru alte strategii:
- Dacă golirea memoriei cache de tabel nu este uciderea server, setaţi mai mare "Cache de compensare timelap" - server-ul dvs. va avea o respiratie între poieni
- Analise de trafic pe forum pentru a verifica şi atunci când este mai puţin - de compensare de executare pentru a modifica acest moment
- Set cache TTL mai mici - mesele mai mici vor fi eliminate astfel de compensare va lua ea însăşi mai putine resurse. De altă parte - server va trebui să solicite mai des Google pentru traduceri.
- EXPERIMENTAL: set "text eliminat rapid locale, cu mese optimiza 'deschis / include / vbenterprisetranslator_functions.php şi în comentariu există 3 linii de cod cu" TABELUL OPTIMIZE LOCAL ". Acest lucru va face text eliminat foarte rapid, fără upgrade-indexurile. NOTĂ: indexurile va creşte, astfel încât va trebui să execute interogarea manual - adică a verifica o dată pe săptămână. În cazul în care va lucra pentru tine, vom implementa noua strategie, în cazul în care indicii vor fi reorganizate nu in fiecare zi.

[tavenger5]

Da, pe vbSEO.

Sunt folosind text eliminat normal la acest moment şi nu pare să ia prea mult timp pentru a obtine lucrurile închise. Cu ştergerea rapidă locale sunt indicii lăsate în tact, şi indexurile obişnuit ştergerea sunt şterse? Va având în indexurile vechi au nici un beneficiu în cazul în care nu sunt optimizate?

Lucrurile par doar pentru a încetini atunci când există o mulţime de trafic pe site-ul şi memoria cache este reconstruit. Sunt sigur că acest lucru se datorează faptului că procesele de Apache nu sunt închise la fel de repede ca in mod normal ar fi (deoarece datele se solicită de la Google).

Este bine să aud că următoarea versiune se va îmbunătăţi la viteza din nou. Am fost doar asigurându-vă că nu a fost nimic altceva aş putea face cu apache tweaking.

[vBET]

Dacă utilizaţi de compensare normale apoi uitat de informatii de la meu. M-am gândit că utilizaţi ultima strategie şi eliminarea cache întregi. Ne pare rău - neînţelegere:) Pur şi simplu lăsaţi-l cum este.

În aşa fel încât pot sfătui să se stabilească Cache TTL mai mare. Mai puţine date vor fi şterse de fiecare dată, astfel că datele vor fi mai puţin pentru a recupera.
Aşa cum am scris am găsit deja o strangulare cu vBSEO + cache gol şi suntem de lucru pe ea:)

Ce poţi să faci este, de asemenea, asiguraţi-vă că serverul dvs. nu este exploataţia cereri de ieşire. Am descoperit că unele servere se comportă ca aceasta în cazul în care mai multe cereri de ieşire sunt de gând să aceluiaşi server. Deoarece 100 de cereri poate dura timp de 1000 x mai mult de 1 cerere (teoretic ar trebui să ia timp 100 x mai mult). Acesta poate fi un firewall, securitate problemă server. Desigur, se poate ca Google pune unele pic de "pedeapsă" în cazul în care astfel de. Deci, dacă puteţi găsi ceva în acest domeniu - poate ajuta. Dacă nu vă rog, aşteptaţi pentru îmbunătăţiri:)