Stran počasi po klirinških predpomnilnika

[tavenger5]

Sem šel skozi, in izvaja vse mogoče trike optimizacijo najdem. To vključuje Nginx kot proxy na apache, vbOptimize z memcached, in vse redne postopke optimizacije vBulletin.

Delam z dvema dual quad jedro procesorja strežnikov z 12 in *** RAM-a, in 15k SAS pogone v napad. Torej, z drugimi besedami, strežniki imajo dovolj moči, da proces vse.

Glavno mesto se začne na desni počasi, ko je cache vBET očiščeno vsakih 15 dni. (Zbirka podatkov pride do nekaj več kot *** po tem 15 dni)> 500k strani na dan se plazil z iskalniki.

Je kaj lahko storim, da poteg apache, da obravnava te zahteve boljši? To so moje trenutne nastavitve apache:
od httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

Od httpd-default.conf:

Timeout 150
Na KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Trik je - če vam ni res, da, potem ne uporabljajte zadnji obračun strategije. Vem, da obstaja če - Ste preverili vse druge strategije obračun? Druge ne bo jasno, celoten predpomnilnik in bo več sredstev, da izhaja iz druge strani.

Naslednja vBET 3.x javnost lahko pomaga - bomo dodali nove napredne parametre uspešnosti za res velik strani. Prav tako smo odkrili ozko grlo s prevodom povezav. V tem trenutku smo izvajali rešitev za Friendly URLs vB v vBET4.x (ne sprosti še) in bomo poskušali, da ga sprejmejo tudi za vBSEO. Če nam uspe, bo odvzel tudi vBET 3.x problem je, da vBSEO prosi za povezave eno po eno, in to daje desetine prošenj Google. Kot sem napisal smo že izvajali rešitev za URLs vB Frinedly - smo naredili zamudo prevod. Problem z vBSEO je, da deluje zunaj vB, po prevodu se zgodi, in tudi ne povem ne potrebuje url za pregled pravilnosti dejansko izvajanim
ali, da ga v izhod.
Veliko podrobnosti - kmalu smo spoznali drug ozko grlo, ki se zgodi samo, kadar je predpomnilnik ne napolni in smo se že delajo na tem področju.

Torej v tem trenutku lahko samo svetujemo, da igrajo z obračunom strategij in drugih parametrov obračuna. Za druge strategije:
- Če s praznjenjem predpomnilnika ene tabele ni ubijanje vaš strežnik, nato pa je večja "Cache obračun timelap '- strežnik bo dih med jasah
- Analise svoj forum prometa in preverite, če je manj - sprememba obračun izvršitve v tem času
- Nastavite nižjo cache TTL - bodo manjše tabele izbriše sama, tako obračun bo manj sredstev. Druga stran - server bo moral vprašati Google pogosteje za prevode.
- EKSPERIMENTALNI: Set 'Quick lokalnih izbris z optimizacijo mize "odprti / Includes / vbenterprisetranslator_functions.php in tam comment 3 vrstic kode z "OPTIMIZE LOCAL TABLE". To bo zelo hitro izbrisa brez nadgradnje indeksov. OPOMBA: indeksov bo rasla, tako da boste morali izvesti poizvedbe ročno - to pomeni, da preveri, enkrat na teden. Če bo to delo za vas bomo izvajali novo strategijo, kjer bo indeks reorganiziran ne vsak dan.

[tavenger5]

Da na vbSEO.

Jaz sem ob uporabi običajnih izbris v tem trenutku in se ne zdi, da traja predolgo, da se stvari ne pozdravi. S hitrim lokalni izbris so indekse levo v takta, in normalno izbris indeksi so preverjeni? Will, ki imajo stare indekse imajo kakršne koli koristi, če se ne optimizirana?

Stvari se le zdi, da počasi navzdol, ko tam je veliko prometa na spletni strani in predpomnilnika se obnovili. Prepričan sem, da je to zato, ker se apache procesi niso zaprte tako hitro, kot se ponavadi (saj se podatki zahtevajo od google).

Lepo je slišati, da bo naslednja različica izboljšati hitrost znova. Jaz sem samo pazite, ni bilo kaj drugega lahko storim z apache tweaking.

[vBET]

Če uporabljate normalni obračun nato pozabil moje namige. Mislil sem, da ga uporabljate zadnjih strategijo in odstranite celotno predpomnilnika. Oprostite - nesporazum Pusti kot je.

Na tak način lahko svetuje, da določi večji Cache TTL. Manj podatki bodo odstranjeni vsakič, tako da bo manj podatkov je, da si opomore.


Kaj lahko storite tudi je, se prepričajte, da vaš strežnik ne drži odhodnih zahtevkov. Ugotovili smo, da nekateri strežniki obnašajo, kot je ta, če veliko odhodnih zahtevkov bodo isti strežnik. Ker lahko 100 prošenj bo 1000 x več časa kot 1 zahtevo (teoretično bi lahko 100 x več časa). To je lahko nekaj požarni zid, strežnik varnostno vprašanje. Seveda je mogoče, da Google postavila nekaj malo "kaznovanje" v takem primeru. Torej, če boste našli nekaj na tem področju - lahko pomaga. Če ne prosim čakati za izboljšave