La mise en cache des requêtes

[tavenger5]

J'ai pris un coup d'oeil à mes requêtes lentes journal et je vois des choses comme ceci:



# 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$


Est-il un moyen pour mettre en cache les requêtes de ce genre? Ces requêtes de la charge sur presque chaque chargement de page.

Oui, j'ai l'invité de cache.

[tavenger5]

Aussi, si vous êtes à exécuter SUPPLÉMENTAIRES sur ces requêtes, il y a cette note: "Impossible OÙ remarqué après la lecture de const tables"

[vBET]

S'il vous plaît aller à Admin CP -> vBET Cache -> Memory Cache vous pouvez définir, là, sur l'utilisation de la mémoire cache (4 moteur: Memcache, APC, XCache eAccelerator).

Ne convient à vos besoins?

PS.
Une seule question - qu'est-ce que le temps de mesure pour le moment de la requête, dans votre rapport?

[tavenger5]

N'a pas la mémoire cache de la fonction, comme la normale, cache, mais stocke les données dans la mémoire? Serait-ce en éliminer quelques-uns de ces requêtes?

La durée de la requête est inscrite dans le premier post avant de la requête.

[vBET]

À l'aide d'Hôtes Cache d'éliminer définitivement de beaucoup de requêtes, puisque, pour les clients les résultats seront stockés dans du pur HTML comme des fichiers, et diffusé à partir de fichiers (jusqu'fichier expire - puis actualisé).
Invité Cache d'éliminer BEAUCOUP de requêtes, depuis plus de trafic sur le forum de clients (y compris les araignées).

Je viens de vérifier nos sources à propos de la Mémoire Cache. Il coopère avec notre Invité Cache - si récemment utilisé les résultats seront prises à partir de la mémoire à partir d'un fichier. Dans ce cas, il ne permettra pas d'éliminer toutes les requêtes (Invité Cache l'a déjà fait).
Encore vBulletin lui-même que je me souviens (pas sûr), en charge de la mémoire cache et peut-être cela permettra d'éliminer certaines des requêtes.

Je sais où est répertorié requête de temps, j'ai demandé sur le temps de mesure. Peut-être que je n'étais pas clair quelle est l'unité de temps? (s, ms, ns?)
Nous avons des indices sur nos tables de cache donc, le temps devrait être de courte durée.

Vous pouvez également essayer de désactiver l'option Admin CP -> vBET Cache -> Database Cache -> Select grouped translations. Lorsqu'il est désactivé, les requêtes sera plus simple (pas de prise en serie), mais il y aura beaucoup plus de requêtes (quelque chose) - peut-être sur votre forum, il serait mieux de requête le plus souvent.
Par exemple la recherche sur vos résultats vous aviez 3 requêtes qui ont donné 22 résultats. Si vous désactivez les résultats en groupes, alors vous aurez le 22 requêtes de donner 1 résultat de chacun, mais la requête sera plus facile (plus simple", OÙ " l'article), donc aussi plus rapide. Si vous avez de la base de données sur un autre serveur, puis définitivement, vous ne devriez pas essayer. Elle vous prenez des résultats par localhost, alors peut-être que tu verras l'amélioration. Ne peut pas dire - ont pour le vérifier.

[tavenger5]

Ok, merci pour l'explication. Je suis à l'aide d'hôtes de cache et de la mémoire cache (xcache), mais je suis toujours étonné de la façon dont de nombreux SÉLECTIONNEZ sont à venir à partir de la base de données.

Le temps de mesure ci-dessus est en secondes.

[vBET]

Il a pris votre base de données de 14 secondes pour la requête? Vraiment? C'est définitivement quelque chose de mal. S'il vous plaît essayez de réparer les tables par Admin CP, peut-être il ya quelque chose de mal. Cela ne devrait pas prendre très longtemps - ces données sont indexés.

[tavenger5]

J'ai le sentiment que certains tableaux sont verrouillage et/ou de l'attente pour le cache de requête, qui est pourquoi ils sont si long à exécuter. Ne pas mentionner que je pourrait utiliser un peu plus de mémoire sur mon serveur de base de données - je suis en train de travailler sur cela.

[vBET]

vBET est à l'aide de tables de cache sans aucun transactions (MYISAM) afin de blocage ne devrait pas être le problème. Vous avez peut-être cassé les indices et MySQL est de faire plein de recherche. Encore une fois merci d'utiliser votre Admin CP pour réparer toutes vos tables et des index (Admin CP -> Maintenance -> Repair / Optimize Tables).