Webstedet langsom efter cache clearing

[tavenger5]

Jeg har gået igennem og gennemført alle de mulige optimering tricks, jeg kan finde. Dette omfatter Nginx som en proxy til Apache, vbOptimize med memcached, og alle de regelmæssige vBulletin optimering procedurer.

Jeg arbejder med to dual quad core processor servere med 12 og *** RAM, og 15k SAS-harddiske i RAID. Så med andre ord, har de servere strøm nok til at behandle alt.

De vigtigste stedet begynder at bremse lige efter vBET cachen er ryddet hver 15 dage. (Databasen bliver til godt *** efter denne 15 dages periode)> 500k sider om dagen er ved at blive gennemgået af søgemaskinerne.

Er der noget jeg kan gøre for at justere apache til at håndterer disse anmodninger bedre? Disse er mine nuværende apache indstillinger:
fra httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

Fra httpd-default.conf:

Timeout 150
KeepAlive On
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Tricket er - hvis du ikke virkelig nødt til det, så skal du ikke bruge sidste clearing strategi. Jeg ved, at der er hvis - Har du tjekket andre clearing strategier? Andre vil ikke klare hele cache og vil tage flere ressourcer til at klare fra den anden side.

Næste vBET 3.x udgivelse kan hjælpe dig - vi vil tilføje nye avancerede performance parametre for rigtig store sider. Vi har også opdaget flaskehals med links oversættelse. I dette øjeblik har vi implementeret løsningen til vB venligt webadresser i vBET4.x (ikke frigivet endnu) og vi vil forsøge at vedtage det også for vBSEO. Hvis det lykkes, vil vi flytte den til også at vBET 3.x Problemet er, at vBSEO beder om links én efter én, og det producerer dusinvis af Google anmodninger. Som jeg skrev vi allerede implementeret løsning til vB Frinedly URL'er - vi lavede forsinket oversættelsen. Problem med vBSEO er, at det virker uden vB, efter oversættelsen sker, og heller ikke fortælle er behov url til at kontrollere rigtigheden af de faktiske en
eller for at sætte det i produktion.
Masser af detaljer - kort, vi kender en flaskehals, der sker, når cache er ikke fyldt, og vi arbejder allerede på dette spørgsmål.

Så i dette øjeblik kan jeg bare råde dig til at lege med clearing strategier og andre clearing parametre. For andre strategier:
- Hvis clearing af en cache tabellen ikke er at dræbe din server, derefter indstille større "Cache clearing timelap '- din server vil tage et åndedrag mellem lysninger
- Analise dit forum trafik og tjekke, når det er mindre - ændring clearing udførelse til denne gang
- Indstil lavere cache TTL - mindre tabeller vil blive ryddet, så clearing selv vil tage færre ressourcer. Andre bivirkninger - serveren bliver nødt til at spørge Google oftere til oversættelser.
- EKSPERIMENTELLE: Sæt 'Quick lokal sletning med optimering af tabeller' åben / Includes / vbenterprisetranslator_functions.php og kommentere der 3 linjer kode med "OPTIMER lokal tabel'. Dette vil gøre virkelig hurtig sletning uden indekser opgradering. BEMÆRK: indekser vil vokse, så du bliver nødt til at udføre forespørgslen manuelt - dvs tjek det en gang om ugen. Hvis det vil arbejde for dig, vi vil gennemføre nye strategi, hvor indeksene vil være reorganiseret ikke hver dag.

[tavenger5]

Ja på vbSEO.

Jeg bruger normal sletning i øjeblikket, og det ser ikke ud til at tage for lang tid at få tingene ryddet. Med hurtig lokal sletning er de indeks tilbage i takt, og den normale sletning indekserne er ryddet? Vil have gamle indekser har nogen fordel, hvis de ikke er optimeret?

Ting synes kun at sætte farten ned, når der er en masse trafik på sitet og cache er ved at blive genopbygget. Jeg er sikker på det er fordi Apache-processer ikke bliver lukket så hurtigt, som de normalt ville (da data der anmodes om fra Google).

Det er godt at høre, at den næste version vil forbedre på hastigheden igen. Jeg var bare at sørge for der var ikke noget andet, jeg kunne gøre med tweaking apache.

[vBET]

Hvis du bruger normale clearing derefter glemt mit tip. Jeg troede, at du bruger seneste strategi og fjerne hele cache. Beklager - misforståelse Bare lade det som det er.

På en sådan måde, jeg kan rådgive at sætte større Cache TTL. Færre data vil blive fjernet hver gang, så færre data vil være at komme sig.


Hvad du også kan gøre, er at sørge for, at din server ikke holder udgående anmodninger. Vi opdagede, at nogle servere opfører sig som dette, hvis mange udgående forespørgsler kommer til samme server. Fordi 100 begæringer kan tage 1000 x længere tid end 1 anmodning (teoretisk bør tage 100 x mere tid). Det kan være nogle firewall, server spørgsmål om sikkerhed. Selvfølgelig kan det være, at Google lægger nogle små 'straf' i sådanne tilfælde. Så hvis du kan finde noget på dette område - det kan hjælpe. Hvis ikke skal du vente til forbedringer