PDA

Gweld Ffurf Llawn: Datrys Safle yn araf ar ôl clirio storfa dros dro



tavenger5
16-03-10, 19:41
Rwyf wedi mynd trwy a'i weithredu pob un o'r triciau Optimization bosibl y gallaf ddod o hyd. Mae hyn yn cynnwys nginx fel procsi i apache, vbOptimize gyda memcached, a'r holl weithdrefnau vBulletin Optimization rheolaidd.

Rwy'n gweithio gyda dau graidd deuol cwad weinyddwyr prosesydd gyda 12 a *** o hwrdd, a gyrru 15k SAS yn y cyrch. Felly, mewn geiriau eraill, y gweinyddwyr yn cael digon o bŵer i brosesu popeth.

Y prif safle yn dechrau araf i'r dde ar ôl y cache vBET cael ei glirio bob 15 diwrnod. (Y gronfa ddata yn cael i ychydig dros *** ar ôl y cyfnod 15 diwrnod)> 500k tudalennau y dydd yn cael eu cropian gan beiriannau chwilio.

A oes unrhyw beth y gallaf ei wneud i tweak apache i handlen yr ceisiadau hyn yn well? Mae'r rhain yn fy lleoliadau apache ar hyn o bryd:
o httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000
O httpd-default.conf:

Goramser 150
KeepAlive Ar
MaxKeepAliveRequests 80
KeepAliveTimeout 3
Oddi UseCanonicalName

vBET
17-03-10, 01:23
Gadewch i mi dyfalu - eich bod wedi vBSEO a llawer o gysylltiadau ar brif dudalen - rwy'n iawn? ;)

Y gamp yw - os nad ydych chi wir rhaid i chi, yna peidiwch defnyddio strategaeth clirio diwethaf. Rwy'n gwybod bod yna os - wnaethoch chi glirio gwirio strategaethau eraill? Ni fydd eraill yn glir cache gyfan a bydd yn cymryd mwy o adnoddau i glirio o ochr arall.

Gall ryddhau 3.x Nesaf vBET eich helpu chi - byddwn yn ychwanegu paramedrau uwch perfformiad newydd ar gyfer tudalennau fawr iawn. Rydym hefyd yn darganfod dagfa gyda chysylltiadau cyfieithu. Ar hyn o bryd rydym wedi gweithredu datrysiad ar gyfer VB URLs cyfeillgar yn vBET4.x (nid rhyddhau eto) a byddwn yn ceisio ei fabwysiadu hefyd ar gyfer vBSEO. Os byddwn yn llwyddo, byddwn yn symud hefyd i vBET 3.x Y broblem yw bod vBSEO gofyn am gysylltiadau fesul un ac mae hyn yn cynhyrchu ddwsinau o geisiadau Google. fel Ysgrifennais ein rhoi ar waith eisoes yn ateb ar gyfer URLs VB Frinedly - rydym yn ei wneud cyfieithiad oedi. Problem gyda'r vBSEO yw ei fod yn gweithio y tu allan i VB, ar ôl cyfieithu yn digwydd a hefyd nid ydynt yn dweud yn anghenion url i wirio cywirdeb o un gwirioneddol
neu ei roi mewn allbwn.
Lot o fanylion - cyn bo hir rydym yn adnabod ei dagfa sydd yn digwydd dim ond pan nad cache ei lenwi, ac rydym eisoes yn gweithio ar y mater hwn.

Felly, ar hyn o bryd y gallaf eich cynghori i chwarae gyda strategaethau clirio a pharamedrau clirio eraill. Ar gyfer strategaethau eraill:
- Os nad yw clirio o un tabl cache yn lladd eich gweinydd, ac yna gosod mwy 'Cache clirio timelap' - bydd eich gweinydd gymryd anadl rhwng llecynnau agored
- Analise eich traffig fforwm a gwirio pan fydd yn llai - gweithredu newid clirio i'r amser hwn
- Gosod cache is TTL - bydd byrddau llai yn cael ei glirio er mwyn clirio ei hun fydd yn cymryd llai o adnoddau. Ochr arall - bydd gweinydd rhaid i ni ofyn Google yn amlach ar gyfer cyfieithiadau.
- ARBROFOL: gosod 'dileu Cyflym lleol gyda byrddau gwneud y gorau' agored / cynnwys / vbenterprisetranslator_functions.php a rhoi sylwadau yno 3 llinell o god gyda 'TABL wneud y gorau LLEOL'. Bydd hyn yn gwneud gwir dilead gyflym heb mynegeion uwchraddio. NODER: Bydd y mynegeion yn tyfu, felly bydd rhaid i chi weithredu yr ymholiad llaw - hy gwirio unwaith yr wythnos. Os bydd yn gweithio i chi, byddwn yn gweithredu strategaeth newydd, lle bydd angen ad-drefnu mynegeion nid bob dydd.

tavenger5
17-03-10, 01:47
Ydy ar vbSEO.

Rwy'n defnyddio ddileu'r arferol ar hyn o bryd ac nid yw'n ymddangos yn cymryd gormod o amser i sicrhau bod pethau'n cael eu clirio. Gyda dileu cyflym lleol yn y mynegeion ar ôl yn tact, ac mae'r mynegeion dileu arferol yn cael eu clirio? A fydd wedi hen mynegeion yn cael unrhyw fudd-dal os nad ydynt yn hoptimeiddio?

Pethau dim ond yn ymddangos i arafu pan mae llawer o draffig ar y safle ac y cache yn cael ei ailadeiladu. Rwy'n siwr mae hyn oherwydd nad apache prosesau yn cael eu cau mor gyflym ag y maent fel arfer yn y byddai (gan fod data'n cael ei gofynnwyd amdano gan google).

Mae'n dda clywed y bydd y fersiwn nesaf yn gwella ar gyflymder eto. Rwyf yn unig oedd yn gwneud yn siwr nad oedd unrhyw beth arall y gallwn ei wneud gyda apache tweaking.

vBET
17-03-10, 02:09
Os ydych yn defnyddio chlirio arferol yna wedi anghofio am fy awgrymiadau. Roeddwn i'n meddwl eich bod yn defnyddio strategaeth diwethaf a thynnu cache gyfan. Mae'n ddrwg gennym - camddealltwriaeth:) Dim ond ei adael fel y mae.

Yn y fath fodd y gallaf roi cyngor i osod mwy Cache TTL. Bydd data llai eu dileu bob tro, felly bydd llai o ddata cael ei adennill.
Wrth i mi ysgrifennu sydd gennym yn barod o hyd i un dagfa gyda vBSEO + cache gwag ac rydym yn gweithio arno:)

Yr hyn y gallwch hefyd wneud yw gwneud yn siŵr nad yw eich gweinydd yn dal geisiadau sy'n mynd allan. Rydym yn darganfod fod rhai gweinyddwyr yn ymddwyn fel hyn os bydd llawer o geisiadau sy'n mynd allan yn mynd i un gweinyddwr. Oherwydd y gall 100 o geisiadau gymryd amser 1000 x mwy nag 1 gais (dylai ddamcaniaethol gymryd amser 100 x fwy). Gall fod yn rhai firewall, mater diogelwch gweinydd. Wrth gwrs, gall fod yn bod Google yn rhoi rhai bach 'gosb' mewn achos o'r fath. Felly, os gallwch ddod o hyd i rywbeth yn y maes hwn - gall helpu. Os na arhoswch ar gyfer gwelliannau:)

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translations by vB Enterprise Translator 4.10.1