PDA

View Full Version: Opgelos Caching navrae



tavenger5
22-02-14, 15:46
Ek het 'n blik op my stadig navrae log en ek sien dinge soos hierdie:



# Time: 140222 8:50:25
# User@Host: database_user[database_user] @ [10.0.0.4]
# Query_time: 7.076817 Lock_time: 0.000065 Rows_sent: 3 Rows_examined: 4174934
use cellphon_forum;
SET timestamp=1393077025;
SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbenterprisetranslator_cache_medium_es help, vbenterprisetranslator_cache_medium_es cache WHERE help.originaltext='U.S. Supreme$
# User@Host: database_user[database_user] @ [10.0.0.4]
# Query_time: 14.198858 Lock_time: 0.000056 Rows_sent: 18 Rows_examined: 4174934
SET timestamp=1393077025;
SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbenterprisetranslator_cache_medium_es help, vbenterprisetranslator_cache_medium_es cache WHERE help.originaltext='******* Xtre$
# User@Host: database_user[database_user] @ [10.0.0.4]
# Query_time: 13.591001 Lock_time: 0.000274 Rows_sent: 1 Rows_examined: 4174934
SET timestamp=1393077025;
SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbenterprisetranslator_cache_medium_es help, vbenterprisetranslator_cache_medium_es cache WHERE help.originaltext='(Espa&ntilde$


Is daar enige manier navrae soos hierdie in die kas? Hierdie navrae laai op byna elke bladsy laai.

Ja, ek het die gas kas op.

tavenger5
22-02-14, 18:15
Ook, as jy hardloop Ekstra op hierdie navrae, daar is hierdie nota: "Onmoontlik WAAR opgemerk na die lees van konst tafels"

vBET
27-02-14, 08:23
Spring na Admin CP -> vBET Cache -> Memory Cache jy kan daar stel oor die gebruik van die geheue kas (4 enjins ondersteun: Memcache, APC, XCache eAccelerator).

Is dit pas by jou behoeftes?

PS.
Een vraag - wat is die tyd maatstaf vir navraag tyd in jou verslag?

tavenger5
28-02-14, 15:37
Nie die geheue kas funksie soos die normale kas, maar stoor die data in die geheue? Sou dit elimineer sommige van daardie vrae?

Die navraag tyd is opgeneem in die eerste post voor die navraag.

vBET
28-02-14, 22:24
Die gebruik van Guest Cache sal beslis skakel baie navrae, want vir gaste resultate sal in plain HTML gestoor word as lêers en gestroom van lêers (tot lêer verstryk - dan verfris).
Guest Cache sal elimineer baie van die navrae, aangesien die meeste van die verkeer op die forum is van die gaste (insluitend spinnekoppe).

Ek het net ons bronne oor Memory Cache nagegaan. Dit werk saam met ons Guest Cache - so onlangs gebruik resultate sal geneem word uit die geheue nie uit lêer. In hierdie geval sal dit nie enige navrae (Guest Cache reeds gedoen het) uit te skakel.
Tog vBulletin homself as ek onthou (nie seker) het ondersteuning vir geheue kas en miskien sal elimineer sommige van die navrae.

Ek weet waar is gelys navraag tyd - ek vra oor tyd te meet. Miskien was ek nie duidelik nie - wat is die eenheid van tyd? (S, MS, ns?)
Ons het indekse op ons kas tafels so tyd moet kort wees.

Ook jy kan probeer opsie om te skakel Admin CP -> vBET Cache -> Database Cache -> Select grouped translations. Wanneer afgeskakel is, dan sal navrae makliker wees (geen neem deur reeks), maar daar sal veel meer navrae (iets vir iets) - miskien op jou forum dit sal beter wees om meer dikwels bevraagteken.
Byvoorbeeld - soek op jou resultate wat jy het 3 navrae wat het 22 resultate. As jy dit afskakel om resultate in groepe, dan sal jy 22 navrae gee 1 gevolg elk, maar die vraag sal makliker (eenvoudiger "waar" afdeling), so ook vinniger. As jy 'n databasis op 'n ander bediener dan finaal moet jy nie probeer om hierdie. Dit wat jy neem die resultate deur localhost, dan miskien sal jy sien verbetering. Kan nie sê nie - het dit te sien.

tavenger5
03-03-14, 04:50
Goed, dankie vir die verduideliking. Ek gebruik gas kas en geheue kas (xcache), maar ek is nog steeds verstom oor hoeveel Select kom uit die databasis.

Die tyd meet bogenoemde is in sekondes.

vBET
03-03-14, 10:15
Dit het jou databasis 14 sekondes vir navraag? Regtig? Dit is definitief iets verkeerd daar. Probeer asseblief tafels te herstel deur Admin CP, miskien is daar iets verkeerd. Dit behoort nie so lank neem - dié data word geïndekseer.

tavenger5
03-03-14, 19:54
Ek het 'n gevoel dat sommige tabelle sluit en / of wag vir die soektog kas, wat is die rede waarom hulle so lank neem om uit te voer. Om nie te praat kon ek 'n paar meer geheue gebruik op my databasis bediener - ek werk wat as goed.

vBET
11-03-14, 12:51
vBET gebruik kas tafels sonder enige transaksies (MYISAM) so blokkeer moet nie die probleem nie. Miskien het jy gebreek indekse en MySQL is ten volle soek. Weer gebruik asseblief jou Admin CP al jou tafels en indekse (om te herstelAdmin CP -> Maintenance -> Repair / Optimize Tables).

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Languages translations made by vBET 4.10.1