Obtenga y coloque pruebas de rendimiento en Google BigTables (y otras bases de datos integradas)

¿Cuáles son algunas formas efectivas de realizar pruebas de rendimiento programáticas en operaciones de bases de datos, especialmente en entornos donde las bases de datos en sí mismas no ofrecen herramientas dedicadas?

Por ejemplo, en Google App Engine, las cargas de página completas se evalúan como una operación que puede incluir operaciones específicas de la base de datos. Es probable que este problema también esté presente en SQLite y otras bases de datos integradas. Como es difícil abstraer por completo (el equivalente de) selecciones e inserciones que deben probarse, ¿hay alguna herramienta de base de datos recomendada para realizar diagnósticos más exhaustivos en este tipo de consultas?

— Brian Ballsun-Stanton
fuente

¿Tiene acceso directo a la base de datos en cuestión?

— Stingervz

Sí, soy yo quien escribe la aplicación. Y aunque el rendimiento de la aplicación es una pregunta diferente, obtengo algunos resultados de rendimiento bastante severos en una consulta desagradable que he escrito.

— Brian Ballsun-Stanton

A veces, una docena de pares de ojos es un mejor diagnóstico que un analizador de consultas ... (ok, no tan a menudo)

— jcolebrand

@Brian Creo que te iría mejor en Stackoverflow con este tipo de pregunta, ya que es más una pregunta de programación que una de DBA.

— IamIC

@IanC Drat. Estoy tratando de llegar a la base de la tabla grande en lugar de al rendimiento en su conjunto. Pero lo eliminaré si la gente no cree que la pregunta sea adecuada. (También estoy tratando de asegurarme de que el sitio no sea oracle / sql-server / mysql todo el tiempo)

— Brian Ballsun-Stanton

Respuestas:

Me parece que su problema es que está intentando probar las métricas de rendimiento que no están bien soportadas en la base de datos subyacente. Esto hace que sea muy difícil comparar el rendimiento entre sistemas porque los enfoques subyacentes son muy diferentes. No creo que sea posible hacer comparaciones de manzanas con manzanas, así como no creo que pueda hacer una comparación de manzanas con manzanas de los enfoques de tipo ORDBMS a los enfoques de tipo RDBMS. Los problemas de rendimiento son demasiado diferentes y si Stonebraker tiene razón en que la optimización de un ORDBMS para las pruebas de TPC-C pierde el punto, entonces, para sistemas que están aún más separados, será imposible. (Creo que él está allí, sin embargo, solo donde entra en juego la funcionalidad ORDBMS).

Creo que lo que necesita para ser honesto es ver cómo usaría cada sistema y crear una herramienta de referencia basada en el enfoque que tomaría con cada uno. Entonces puede decir, al menos para ese flujo de trabajo, que el punto de referencia muestra algo específico. Sin embargo, no veo cómo puedes generalizar. Además, puede ejecutarlo en un generador de perfiles para obtener información adicional sobre dónde se pasa el tiempo en la ejecución de prueba en varios motores.

Sin embargo, la evaluación comparativa de db es muy difícil de hacer significativa en las mejores circunstancias y cuando se comparan sistemas diferentes es imposible generalizar.

— Chris Travers
fuente

Appstats es la herramienta clave para medir el rendimiento en App Engine. Mostrará el tiempo utilizado para cada RPC, incluido el almacén de datos, memcache, urlfetch y solicitudes de correo en un gráfico gráfico. Normalmente, las solicitudes aparecen como una "escalera" donde cada solicitud comienza en el punto en que finalizó la solicitud anterior, en la siguiente línea hacia abajo.

Si utiliza las solicitudes asíncronas avanzadas en ndb, puede ver que las solicitudes suceden en paralelo.

Esta herramienta me ha sido de gran ayuda para ver dónde se está gastando el tiempo y cómo optimizar las consultas.

— Brent Washburne
fuente