Caching-query ' s

[tavenger5]

Ik nam een kijkje op mijn slow query log en ik ben het zien van dingen als dit:

# 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 er een manier om de cache-query ' s als deze? Deze query ' s laden op bijna elke pagina te laden.

Ja, ik heb de gast cache op.

[tavenger5]

Ook, als je je om te draaien EXTRA op deze vragen, is er deze opmerking: "het is Onmogelijk WAAR gemerkt na het lezen van const tabellen"

[vBET]

Ga naar Admin CP -> vBET Cache -> Memory Cache u kunt instellen dat er op het gebruik van het cachegeheugen (4 motoren ondersteund: Memcache, APC, XCache eAccelerator).

Is dit uw behoeften past?

PS.
Een vraag - wat is de tijd te meten voor het uitvoeren van de query in uw rapport?

[tavenger5]

Niet in het geheugen cache functie als de normale cache, maar slaat de gegevens op in het geheugen? Zou dat het elimineren van een aantal van deze vragen?

De query wordt weergegeven in de eerste post, voordat de query.

[vBET]

Met Gast-Cache zal definitief elimineren veel van query ' s, omdat voor de gasten zullen de resultaten worden opgeslagen in platte HTML-bestanden en het streamen van bestanden (tot bestand verloopt - dan vernieuwd).
Gast Cache zal elimineren VEEL van query ' s, aangezien de meeste van het verkeer op het forum is van de gasten (met inbegrip van spinnen).

Maar ik checkte onze bronnen over van het Cachegeheugen. Het werkt samen met de Cache - zo recent gebruikte resultaten zal worden genomen uit het geheugen niet uit bestand. In dit geval zal het niet het elimineren van elke query ' s (Gast Cache al deed).
Nog vBulletin zelf als ik me goed herinner (niet zeker) heeft ondersteuning voor geheugen cache en misschien hierdoor wordt voorkomen dat sommige van query ' s.

Ik weet wel waar is vermeld query tijd - ik was de vraag over de tijd te meten. Misschien was ik niet duidelijk - wat is de eenheid van tijd? (s, ms, ns?)
We hebben indexen op onze cache tabellen dus tijd moet kort zijn.

Ook kunt u proberen om de optie uitschakelen Admin CP -> vBET Cache -> Database Cache -> Select grouped translations. Wanneer dit uitgeschakeld is, worden query ' s wordt eenvoudiger (geen het nemen van de serie), maar er zullen veel meer query ' s (iets voor iets) - misschien op uw forum-het beter om de query vaker.
Bijvoorbeeld kijken op je resultaten, je had 3 query ' s die gaf 22 resultaten. Als u uitschakelen nemen van de resultaten in de groepen dan heb je 22 query ' s geven 1 resultaat, maar de vraag zal worden gemakkelijker (eenvoudiger 'WAAR' sectie) dus ook sneller. Als u de database op een andere server dan definitief moet je het niet proberen. Je bent van het nemen van resultaten door localhost, dan misschien zie je verbetering. Kan niet zeggen - hebben om het te controleren.

[tavenger5]

Oké, bedankt voor het uitleggen. Ik ben het met gast en cache geheugen cache (xcache), maar ik ben nog steeds verbaasd over hoe veel SELECTEER s zijn afkomstig uit de database.

De tijd meten boven is in seconden.

[vBET]

Het duurde uw database 14 seconden voor query? Echt? Het is definitief iets niet klopt. Probeer het te repareren tabellen door Admin CP, misschien is er iets verkeerd. Het mag niet zo lang - deze gegevens zijn geïndexeerd.

[tavenger5]

Ik heb het gevoel dat sommige tafels zijn vergrendelen en/of om te wachten voor de query-cache, dat is waarom ze zo lang om uit te voeren. En niet te vergeten ik kan wel wat meer geheugen op mijn database server - daar ben ik mee bezig.

[vBET]

vBET is het gebruik van cache tabellen zonder enige transacties (MYISAM) zodat het blokkeren mag niet het probleem. Misschien heb je gebroken indexen en MySQL is volledig zoek. Wederom gebruik je Admin CP te repareren al uw tabellen en indexen (Admin CP -> Maintenance -> Repair / Optimize Tables).