Lapas lēns pēc cache klīringa

[tavenger5]

Es esmu gājusi cauri un īstenot visas iespējamās optimizācijas triku varu atrast. Tas ietver nginx kā proxy uz apache, vbOptimize ar memcached un visas regulārās vBulletin optimizācijas procedūras.

Es esmu darba ar diviem dual četrkodolu procesoru serveriem ar 12 un *** RAM, un 15.k SAS diskus RAID. Tātad, citiem vārdiem sakot, serveri ir pietiekami daudz jaudas, lai apstrādātu visu.

Galvenās atrašanās vietas sāk lēni uzreiz pēc vBET cache tiek izvadīts ik pēc 15 dienām. (Datu bāze izpaužas nedaudz vairāk *** pēc šī 15 dienu laikā)> 500k lapām dienā, tiek pārmeklēts ar meklētājprogrammas.

Vai ir kaut ko es varu darīt, lai kniebiens apache uz rokturiem šos pieprasījumus labāk? Šīs ir manas pašreizējās apache iestatījumus:
no httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

No httpd-default.conf:

Noildze 150
Keepalive On
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Triks ir - ja jums nav īsti ir, tad nelietojiet pēdējais klīringa stratēģiju. Es zinu, ka nav ja - Vai jūs pārbaudīt citas klīringa stratēģijas? Citas nebūs skaidrs viss cache un prasīs vairāk resursu, lai notīrītu no otras puses.

Nākamā vBET 3.x atbrīvošanu var palīdzēt jums - mēs pievienot jaunu progresīvu veiktspējas parametriem ļoti lieliem lapām. Mēs arī atklājām nosprostojumiem saitēm tulkojumu. Uz doto brīdi mums ir jāīsteno risinājums vB Friendly URL vBET4.x (nav atbrīvota vēl) un mēs mēģināsim to ieviest arī vBSEO. Ja mums izdosies, mēs pāriet arī uz vBET 3.x ir tas, ka vBSEO lūdz viena saitēm viens un tas rada desmitiem Google pieprasījumus. Kā es rakstīja mums jau īstenots risinājums vB Frinedly URL - mēs, kas kavējas tulkojumu. Problēma ar vBSEO ir, ka tas strādā ārpus VB, pēc tulkošanas notiek, un arī nav pateikt tas nepieciešams url, lai pārbaudītu pareizību vienu faktisko
vai nodot to ražošanas jauda.
Daudz detaļas - īsi mēs zinu vienu vājo vietu, kas notiek tikai tad, kad cache nav piepildīts, un mēs jau strādājam pie šī jautājuma.

Tātad, šajā brīdī es varu tikai ieteikt jums spēlēt ar klīringa stratēģijas un citus klīringa parametriem. Par citas stratēģijas:
- Ja ieskaita vienu cache tabula nav nogalināt jūsu serveri, tad noteikti lielāku "Cache mijieskaita timelap" - jūsu serveris elpu starp klajumi
- Analise savu forumu satiksmi un pārbaudīt, ja tas ir mazāk - mainīt norēķinu izpildei, lai šajā laikā
- Noteikt mazāku cache TTL - mazākas tabulas tiks dzēsti, lai mijieskaita pati pieņems mazāk resursu. Otru pusi - serveris būs jālūdz Google biežāk par tulkojumiem.
- EKSPERIMENTĀLĀ: Set "Quick vietējo svītrots ar optimizētu tabulas" atvērtā / Includes / vbenterprisetranslator_functions.php un komentēt tur 3 rindiņas kodu ar 'PILNVEIDOŠANA LOCAL TABULA'. Tas padara ļoti ātri dzēšanu bez indeksi jauninājums. PIEZĪME: indeksi pieaugs, tāpēc jums būs izpildīt vaicājumu manuāli -, ti, pārbaudīt to vienu reizi nedēļā. Ja tas darbosies, lai jūs, mēs ieviest jaunu stratēģiju, kur indeksi tiks reorganizētas ne katru dienu.

[tavenger5]

Jā, par vbSEO.

Es, izmantojot parasto dzēšanas brīdī, un tas, šķiet, nav pārāk ilgi, lai iegūtu lietas notīrīta. Ar ātru vietējie svītrojums ir indeksi palicis takts, un normālu dzēšanu indeksi tiek dzēsti? Vai ar veco indeksi ir kāds labums, ja tie nav optimizēti?

Things tikai šķiet, palēnināt, ja tur ir daudz cilvēku uz vietas, un cache tiek pārbūvēta. Es esmu pārliecināts, ka tas ir tāpēc, ka apache procesi netiek slēgti tik strauji, kā tie parasti (jo dati tiek pieprasīta no google).

Ir labi dzirdēt, ka nākamā versija būs uzlabot ātrumu vēlreiz. Man bija tikai pārliecinoties, ka nav kaut kas cits es varētu darīt ar tweaking apache.

[vBET]

Ja jūs izmantojat parasto klīringa tad aizmirsa par manu mājieni. Es domāju, ka jūs lietojat pēdējo stratēģiju un noņemt visu kešatmiņu. Sorry - pārpratums Vienkārši atstāt to kā tas ir.

Tādā veidā es varu ieteikt, lai noteiktu lielāku Cache TTL. Mazāk dati tiks noņemti katru reizi, tāpēc mazāk dati būs atgūt.


Ko jūs arī varat darīt, ir pārliecināties, ka jūsu serveris, kam nav izejošo pieprasījumu. Mēs atklājām, ka daži serveri uzvedas kā šis, ja daudzi izejošie pieprasījumi dodaties uz paša servera. Tā kā 100 pieteikumus var pieņemt 1000 x vairāk laika nekā pieprasījuma 1 (teorētiski būtu jāveic 100 x vairāk laika). Tas var būt kāds firewall, servera drošības jautājums. , Protams, tas var būt, ka Google liek dažiem maz "sods" šādā gadījumā. Tātad, ja jūs varat atrast kaut ko šajā jomā - tas var palīdzēt. Ja nav, lūdzu, gaidīt uzlabojumu