Pregunta sobre el mecanismo de caché de Solr

Question

Estoy trabajando en un proyecto de Apache Solr. (distribuido en un entorno de nube - instancias de Amazon ec2).

Me he dado cuenta de que Solr hace un excelente trabajo en el almacenamiento en caché de los resultados. Cuando ejecuto las mismas consultas de nuevo, el responsable declara Solr QTime 0 o 1 milisegundo.

Quiero poner a prueba el sistema Solr. Por lo tanto, tengo una lista limitada de consultas que podría usar (50 000 consultas únicas). ¡El problema ahora es que todas las consultas están en caché!

Cuando hago una prueba de esfuerzo - después de 5 minutos más o menos - todas mis consultas se dan en Solr & ejecutadas. Esto hace que el sistema se transforme en una carga pesada :) (este era el objetivo). Pero luego, cuando ejecuto el mismo conjunto de consultas nuevamente, ¡QTime es casi cero! -> Solr tiene un tiempo fácil & no está estresado.

Mi pregunta es: ¿Cómo se puede convertir TODOS los cachés de Solr (ambos en caché de Solr y Lucence)? ¿O cómo se puede limitar el caché?

He intentado convertir todo el caché interno de Solr, pero el caché aún se mantiene. (QueryResultCache y FieldCache) Nota: La configuración menciona que Lucence tomará la administración de un caché interno. ¿Tal vez este caché sea el problema?

Es curioso que todas las 50 000 consultas se puedan almacenar en la memoria caché, al salir de la caja.

Answer 1

Puede comentar el filterCache, queryResultCache and documentCache en su configuración. Lucene's FieldCache cannot be disabled.

Aunque realmente no tiene ningún sentido hacerlo, incluso para la evaluación comparativa. ¿Deshabilitaría también el almacenamiento en caché de disco en su sistema operativo? Cachés de CPU (los tres niveles)? ¿El caché interno de cada disco duro?

Los cachés son parte del sistema; si los deshabilita, no simulará con precisión lo que sucede en la producción, lo que hace que el punto de referencia sea inútil.

Answer 2

Apagar memorias caché es una idea excelente, al menos aquellas que son específicas de la aplicación. Me refiero a un punto de referencia en este caso para encontrar la respuesta/costo de una consulta que no se haya visto antes; a diferencia de aquellos que son populares dentro de un caché caducan.

Parece que quiere métricas que le indiquen cómo funciona el sistema de búsqueda; no el caché de consultas.

Las respuestas anteriores están realmente fuera del campo, sugiriendo que todos los puntos de referencia deberían medir lo mismo, "su propia definición de" rendimiento en la vida real. Así no es como funciona la ingeniería.

En cuanto a la observación sobre "cachés de disco". No hay cachés de disco en Linux; solo un caché de página; si esa página se conserva en el disco, si se crea y se destruye en la memoria o las asignaciones previas para sistemas de archivos grandes que son inteligentes ... son todas las páginas.

Existe una ventaja de la evaluación comparativa con cachés ... si se molesta en medir las métricas de rendimiento de caché. duh.

BTW, entre "-server" y "XXcompileThreshold" desea asegurarse de que su primer gran conjunto de consultas sea lo suficientemente aleatorio o específicamente elegido para ejercer tantas vías de función en Solr/Lucene como sea posible; así que JIT está activo y algo asentado.