Lloc lent després de buidar la memòria cau

[tavenger5]

He passat per i implementat tots els trucs d'optimització possible que pugui trobar. Això inclou Nginx com a proxy per apache, vbOptimize amb memcached, i tots els procediments regulars d'optimització de vBulletin.

Estic treballant amb dos servidors de quàdruple processador de doble nucli amb 12 i *** de RAM i 15K SAS a raid. Per tant, en altres paraules, els servidors tenen el poder suficient per processar tot.

El lloc principal comença a disminuir immediatament després de la memòria cau de VBET s'esborra cada 15 dies. (La base de dades arriba a poc més de *** després d'aquest termini de 15 dies)> 500k pàgines al dia s'estan rastrejant els motors de cerca.

Hi ha res que pugui fer per modificar Apache per que s'encarrega d'aquestes peticions millor? Aquests són els meus valors actuals de apache:
de httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

Des httpd-default.conf:

Temps d'espera 150
El KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Deixa'm endevinar - tens vBSEO i parcel·la de nexes en pàgina major - sóc dret?

El truc és - si vostè realment no ha de fer-ho, no utilitzi l'estratègia de compensació passat. Jo sé que hi ha si - S'ha marcat altres estratègies de compensació? Altres no es buida la memòria cau sencera, i tingui més recursos per eliminar des de l'altre costat.

Següent VBET alliberament 3.x pot ajudar - anem a afegir nous paràmetres de rendiment avançat de pàgines molt gran. També descobrim coll d'ampolla amb la traducció de vincles. En aquest moment hem posat en marxa una solució per a les adreces URL v solters a vBET4.x (no publicat encara) i anem a tractar d'adoptar també per Matías. Si ho aconseguim haurem de moure també a VBET 3.x La qüestió és que Matías li pregunta per als enllaços d'un en un, i això produeix dotzenes de sol.licituds de Google. Com he escrit que ja va implementar la solució per VB URL Frinedly - vam fer la traducció retard. Problema amb Matías és que treballa fora de BB, després de la traducció que passa i que a més no es necessita dir url per comprovar la correcció d'un real
o per posar-lo en producció.
Gran quantitat de detalls -, poc se sap un coll d'ampolla que es produeix només quan la memòria cau no és ple i ja estem treballant en aquest tema.

Així que en aquest moment només puc aconsellar a jugar amb les estratègies de compensació i altres paràmetres de compensació. Per a altres estratègies:
- Si la neteja d'una taula de la memòria cau no està matant al seu servidor, a continuació, establir més gran "Netejant timelap '- el servidor es respira entre els clars
- Analistes el trànsit del seu fòrum i veure quan és menor - Execució clar canvi en aquest moment
- Establir menor memòria cau TTL - mida de les taules s'esborrarà tan clar en si tindrà menys recursos. Un altre costat - el servidor haurà de demanar a Google amb més freqüència per les traduccions.
- EXPERIMENTAL: 'Quick eliminació local amb taules optimitzar "conjunt obert / Includes / vbenterprisetranslator_functions.php i el comentari que tres línies de codi amb 'OPTIMITZA TABLE LOCAL. Això farà que l'eliminació molt ràpid, sense actualitzar els índexs. NOTA: Els índexs de créixer, de manera que haurà d'executar la consulta manualment - és a dir, comprovar un cop per setmana. Si va a treballar perquè anem a implementar la nova estratègia, on els índexs no es va a reorganitzar cada dia.

[tavenger5]

Sí a Matías.

Estic usant l'eliminació normal en el moment i no sembla tenir massa temps per fer les coses fora. Amb l'eliminació ràpida locals són els índexs de l'esquerra en el tacte, i els índexs d'eliminació normal, s'esborren? El tenir índexs d'edat tenen cap benefici si no s'han optimitzat?

Les coses s'assemblen més lent quan hi ha molt trànsit en el lloc i la memòria cau està sent reconstruïda. Estic segur que això es deu als processos de apatxe no es tanquen tan ràpid com ho faria normalment (ja que les dades que es demanen de google).

És bo saber que la propera versió es millora la velocitat de nou. Jo era simplement assegurar-se que no hi havia res més que pogués fer amb apache ajustos.

[vBET]

Si utilitzeu neteja normal, llavors es va oblidar dels meus suggeriments. Vaig pensar que vostè està utilitzant l'última estratègia i eliminar la memòria cau sencera. Ho sentim - malentès Només has de deixar-lo com està.

De tal manera que pugui assessorar el conjunt major memòria cau TTL. Menys de dades seran eliminats cada vegada, així que menys dades es recuperar.
Com vaig escriure ja vam trobar un coll d'ampolla amb vBSEO + la memòria cau buida i nosaltres estan treballant en ell

El que també es pot fer és assegurar-se que el servidor no està duent a terme sol.licituds de sortida. Hem descobert que alguns servidors es comporten com si aquest nombre de sol.licituds de sortida van a un mateix servidor. A causa de que 100 sol.licituds pot prendre temps x 1000 més d'una sol licitud (en teoria s'haurien de prendre el temps 100 vegades més). Pot ser un servidor de seguretat, tema de la seguretat del servidor. Per descomptat, pot ser que Google posa una mica petita "càstig" en aquest cas. Així que si vostè pot trobar alguna cosa en aquest camp - que poden ajudar. Si no s'esperi a que les millores