La caché de consultas

[tavenger5]

Eché un vistazo a mi registro de consultas lentas y estoy viendo cosas como esta:



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


¿Hay alguna manera de la caché de consultas como ésta? Estas consultas de carga en casi cada carga de la página.

Sí, tengo el invitado de caché.

[tavenger5]

También, si vas a ejecutar EXTRA en estas consultas, hay esta nota: "Imposible DONDE notado después de leer const tablas"

[vBET]

Por favor vaya a Admin CP -> vBET Cache -> Memory Cache se puede establecer que hay en el uso de la memoria caché (4 motores compatibles: Memcache, APC, XCache, eAccelerator).

¿Este ajuste a sus necesidades?

PS.
Una pregunta - ¿cuál es la medida de tiempo para el momento de la consulta en su informe?

[tavenger5]

No la memoria caché de la función igual que la normal caché, pero almacena los datos en la memoria? Habría que eliminar algunas de las consultas?

El tiempo de consulta aparece en el primer post antes de la consulta.

[vBET]

El uso de Huéspedes Caché de eliminar definitivamente muchas de las consultas, ya para los huéspedes resultados serán almacenados en formato HTML, como archivos y streaming de archivos (hasta el archivo vence - a continuación, se actualiza).
Invitado Caché de eliminar la gran cantidad de consultas, ya que la mayoría del tráfico en el foro de invitados (como las arañas).

Acabo de comprobar nuestras fuentes acerca de la Memoria Caché. Colabora con nuestro Invitado Caché - tan utilizada recientemente los resultados serán tomados de la memoria de archivo. En este caso no va a eliminar cualquier consulta (Invitado Caché ya lo hizo).
Todavía vBulletin en sí como recuerdo (no estoy seguro) tiene soporte para memoria caché y tal vez esto va a eliminar algunas de las consultas.

Yo sé donde aparece el momento de la consulta - me estaba preguntando acerca de medida de tiempo. Tal vez no fui clara de lo que es la unidad de tiempo? (s, ms, ns?)
Tenemos índices en nuestras tablas de caché por lo que el tiempo debe ser corto.

También puede intentar deshabilitar la opción Admin CP -> vBET Cache -> Database Cache -> Select grouped translations. Cuando se desactiva, las consultas será más sencillo (no tomar por serie), pero habrá mucho más consultas (algo por algo), - quizás en su foro será mejor consultar más a menudo.
Por ejemplo buscando en sus resultados que había 3 consultas que dio el 22 de resultados. Si deshabilita resultados en grupos, a continuación, usted tendrá 22 consultas dar 1 resultado de cada uno, pero la consulta será más fácil (más simple 'DONDE' sección) así también más rápido. Si usted tiene la base de datos en otro servidor, a continuación, definitivamente no intente esto. Lo que ustedes están teniendo resultados por localhost, entonces tal vez usted va a ver una mejoría. No se puede decir que se tiene que comprobar.

[tavenger5]

Bueno, gracias por la explicación. Estoy usando huésped de caché y la memoria caché (xcache), pero todavía estoy sorprendido por cómo muchos SELECT vienen de la base de datos.

La medida de tiempo de arriba es en segundos.

[vBET]

Tomó su base de datos de 14 segundos para la consulta? ¿De verdad? Es definitivamente algo hay mal. Por favor, intente reparar tablas por Admin CP, tal vez hay algo mal. No se debe tomar mucho tiempo - los datos están indizadas.

[tavenger5]

Tengo la sensación de que algunas tablas de bloqueo y/o de espera para la consulta de la caché, que es por qué se están tomando tanto tiempo para ejecutar. Por no hablar de que yo podría utilizar un poco más de memoria en mi servidor de base de datos - estoy trabajando en eso.

[vBET]

vBET es el uso de tablas de caché sin ningún tipo de transacciones (MYISAM) bloqueando así no debería ser el problema. Tal vez usted ha roto índices y MySQL es hacer de búsqueda completa. Una vez más, por favor use su pc de Administración para reparar todas las tablas e índices (Admin CP -> Maintenance -> Repair / Optimize Tables).