Site traag wordt nadat cache clearing

[tavenger5]

Ik heb doorgemaakt en geïmplementeerd alle mogelijke optimalisatie trucjes die ik kan vinden. Dit omvat nginx als een proxy voor apache, vbOptimize met memcached, en alle reguliere vBulletin optimalisatie procedures.

Ik ben bezig met twee dual quad core processor servers met 12 en *** van de ram, en 15k sas-schijven in raid. Dus, met andere woorden, de servers hebben genoeg kracht om alles te verwerken.

De belangrijkste site begint langzaam naar rechts na de vBET cache is gewist om de 15 dagen. (De database krijgt om iets meer dan *** na deze periode van 15 dagen)> 500k pagina's per dag worden doorzocht door zoekmachines.

Is er iets wat ik kan doen om apache te tweaken behandelt deze verzoeken beter? Dit zijn mijn huidige apache instellingen:
van httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
Maxclients 180
MaxRequestsPerChild 1000

Van httpd-default.conf:

Time-out 150
Op KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

De truc is - als je niet echt moet, dan geen gebruik maken van vorig clearing strategie. Ik weet dat er is als - Heb je aangevinkt andere clearing strategieën? Andere zal niet duidelijk hele cache en zal meer middelen uit andere kant.

Volgende vBET 3.x release kan u helpen - we zullen nieuwe, geavanceerde performance parameters toe te voegen voor echt grote pagina's. We ontdekten ook knelpunt met links vertaling. Op dit moment hebben wij geïmplementeerde oplossing voor VB Friendly URL's in vBET4.x (nog niet uit) en we zullen proberen om ook vast te stellen het voor vBSEO. Als we daarin slagen zullen we het ook verhuizen naar 3.x vBET Het probleem is dat vBSEO vraagt voor links een voor een en dit levert tientallen Google verzoeken. Zoals ik schreef we reeds geïmplementeerde oplossing voor VB Frinedly URL's - we hebben uitgesteld vertaling. Probleem met vBSEO is dat het werkt buiten vB, na vertaling gebeurt en ook niet te vertellen heeft moet url om te controleren of juistheid van de werkelijke een
of om het in output.
Lot van details - kort weten we een bottleneck die gebeurt alleen wanneer cache niet is gevuld en we zijn al bezig met deze kwestie.

Dus op dit moment kan ik alleen maar adviseren om te spelen met clearing strategieën en andere clearing parameters. Voor andere strategieën:
- Als het wissen van een cache tabel is niet het doden van uw server, dan moet groter 'Cache clearing timelap' - uw server zal een adem tussen de open plekken te nemen
- Analise je forum het verkeer en controleren wanneer het is minder - verandering clearing uitvoering aan deze tijd
- Stel een lagere cache TTL - kleinere tafels worden gewist, zodat clearing zelf zal minder middelen te nemen. Andere kant - server zal moeten Google vragen steeds vaker voor vertalingen.
- EXPERIMENTEEL: Set 'Snel lokale verwijdering van optimaal tabellen' open / Includes / vbenterprisetranslator_functions.php en daar comment 3 lijnen van de code met 'OPTIMALISEREN lokale tabel'. Dit maakt heel snel verwijderen zonder indexen upgrade. LET OP: indexen zal groeien, zodat u de query handmatig uit te voeren hebben - dat wil zeggen check it keer per week. Of het zal voor u werken wij zullen implementeren nieuwe strategie, waar de indexen niet zal worden gereorganiseerd elke dag.

[tavenger5]

Ja op vBSEO.

Ik gebruik normaal deletie op het moment en het lijkt niet te lang duurt om dingen gewist. Met snelle lokale verwijderen zijn de indices nog in tact, en de normale verwijderen indexen worden gewist? Zal het hebben van oude indexen enig voordeel als ze niet optimaal?

Dingen die alleen lijken te vertragen als er veel verkeer op de site en de cache wordt herbouwd. Ik weet zeker dat dit is omdat apache processen worden niet afgesloten zo snel als ze normaal zouden (aangezien er gegevens worden opgevraagd bij google).

Het is goed om te horen dat de volgende versie weer zal verbeteren op snelheid. Ik was gewoon voor dat er niet iets anders kon ik doen met apache tweaken.

[vBET]

Als u gebruik maakt van een normale clearing vervolgens vergat mijn hints. Ik dacht dat je laatste strategie gebruikt en verwijder hele cache. Sorry - misverstand Laat het zoals het is.

In zo'n manier kan ik adviseren om grotere Cache TTL in te stellen. Minder gegevens zal telkens worden verwijderd, zodat er minder gegevens zullen worden om te herstellen.


Wat je ook kunt doen is ervoor zorgen dat uw server niet is uitgaande verzoeken bedrijf. We ontdekten dat sommige servers zich gedragen als dit als een groot aantal uitgaande verzoeken gaan naar dezelfde server. Omdat de 100 verzoeken kunnen nemen 1000 x meer tijd dan een verzoek (in theorie zou moeten 100 x meer tijd in beslag nemen). Het kan enkele firewall-, server-security probleem worden. Natuurlijk kan het zijn dat Google een aantal kleine 'straf' brengt in een dergelijk geval. Dus als je iets kunt vinden in dit gebied - het kan helpen. Zo niet dan wachten op verbeteringen