Site långsam efter cache clearing

[tavenger5]

Jag har gått igenom och genomfört alla de möjliga optimering tricks jag kan hitta. Detta inkluderar nginx som en proxy med apache, vbOptimize med memcached, och alla de vanliga vBulletin förfaranden optimering.

Jag arbetar med två dual processor Quad Core-servrar med 12 och *** RAM och 15k SAS-enheter i RAID. Så, med andra ord, de servrar har tillräckligt med kraft för att bearbeta allt.

Den största anläggningen börjar avta direkt efter att vBET cachen rensas var 15 dagar. (Databasen blir för drygt *** efter denna 15 dagars period)> 500k sidor per dag som genomsöks av sökmotorer.

Finns det något jag kan göra för att justera apache för att hantera dessa önskemål bättre? Dessa är mina nuvarande apache inställningar:
från httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
Maxclients 180
MaxRequestsPerChild 1000

Från httpd-default.conf:

Timeout 150
KeepAlive På
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Tricket är - om du inte verkligen måste, ska du inte använda senaste clearing strategi. Jag vet att det finns om - Har du kontrollerat andra clearing strategier? Andra kommer inte att klara hela cacheminnet och tar mer resurser för att rensa från andra sidan.

Nästa vBET 3.x utgåva kan hjälpa dig - vi kommer att lägga till nya avancerade prestanda parametrar för riktigt stora sidor. Vi upptäckte också flaskhals med länkar översättning. Just nu har vi implementerat lösningen för VB Friendly webbadresser i vBET4.x (inte släppts ännu) och vi kommer att försöka införa det även för vBSEO. Om vi lyckas kommer vi att flytta den också vBET 3.x Problemet är att vBSEO ber om länkarna en efter en och detta ger dussintals Google förfrågningar. Som jag skrev vi redan infört lösning för VB Frinedly webbadresser - vi gjorde försenade översättning. Problem med vBSEO är att det fungerar utanför VB, efter översättning händer och dessutom inte berätta inte behöver url att kolla riktigheten av de faktiska en
eller för att uttrycka det i produktionen.
Massor av detaljer - kort vet vi en flaskhals som uppstår endast i samband cache inte är fylld och vi arbetar redan med denna fråga.

Så just nu kan jag bara råda dig att spela med clearing strategier och andra parametrar clearing. För andra strategier:
- Om clearing av en cache tabellen är inte att döda din server, sedan ställa större "Cache clearing timelap" - din server kommer att ta ett andetag mellan hyggen
- Analise ditt forum trafik och kolla när det är mindre - ändra clearing utförande till denna tid
- Ställ in lägre cache TTL - mindre bord kommer att rensas så rensa själv kommer att ta mindre resurser. Andra sidan - servern måste be Google oftare för översättningar.
- EXPERIMENTELL: Set "Quick lokala raderingen med att optimera tabeller" öppna / Includes / vbenterprisetranslator_functions.php och kommentera det 3 rader kod med "OPTIMERA lokal tabell". Detta kommer att göra riktigt snabbt bort utan index uppgradering. OBS: index kommer att växa, så du måste köra frågan manuellt - det vill säga kontrollera det en gång per vecka. Om det kommer fungera för dig att vi kommer att genomföra nya strategi, där index kommer att omorganiseras inte varje dag.

[tavenger5]

Ja i vbSEO.

Jag använder vanlig radering för tillfället och det verkar inte ta för lång tid att få saker rensas. Med snabba lokala radering är indexen kvar i takt, och den normala radering index rensas? Kommer att ha gamla index har någon nytta om de inte är optimerade?

Saker verkar endast för att sakta ner när det är mycket trafik på platsen och cachen byggs om. Jag är säker på att detta beror på att apache processerna inte att stängas så fort som de normalt skulle (eftersom data som efterfrågas från Google).

Det är bra att höra att nästa version kommer att öka på fart igen. Jag var bara att se till att det inte fanns något annat jag kunde göra med tweaking Apache.

[vBET]

Om du använder vanlig clearing sedan glömt bort mitt tips. Jag trodde att du använder senaste strategi och ta bort hela cache. Tyvärr - missförstånd Bara lämna det som det är.

På så sätt kan jag råda att ställa större Cache TTL. Mindre data kommer att tas bort varje gång, så mindre data kommer att återhämta sig.


Vad du också kan göra är att se till att din server inte håller utgående förfrågningar. Vi upptäckte att vissa servrar bete sig så om många utgående förfrågningar kommer att samma server. Eftersom 100 ansökningar kan ta 1000 x längre tid än en begäran (teoretiskt bör ta 100 x mer tid). Det kan vara någon brandvägg, server säkerhetsproblem. Visst kan det vara att Google sätter någon liten "straff" i ett sådant fall. Så om du kan hitta något på detta område - det kan hjälpa. Om inte du vänta på förbättringar