Prueba de gastos generales de rendimiento de la solución ORM personalizada: cómo hacerlo.

Question

He creado un prototipo de una herramienta ORM personalizada utilizando la programación orientada a aspectos (PostSHarp) y logrando la ignorancia de persistencia (antes del tiempo de compilación). Ahora traté de averiguar cuánto sobrecarga presenta en comparación con el uso puro de DataReader y ADO.NET. Hice un caso de prueba: inserte, lea, elimine datos (aproximadamente 1000 registros) en MS SQL Server 2008 y MySQL Community Edition. Ejecuto esta prueba varias veces usando ADO.NET puro y mi herramienta personalizada.

Espero que los resultados dependerán de muchos factores: memoria, intercambio, CPU, otros procesos, así que realicé pruebas varias veces (20-40). Pero los resultados fueron realmente inesperados. Simplemente difieren demasiado entre esos casos. Si solo hubiera algunos valores extremos, podría ignorarlos (tal vez el intercambio sucedió o algo así) pero eran tan diferentes que estoy seguro de que no puedo confiar en este tipo de pruebas. Casi la mitad de veces mi ORM mostró un 10% mejor rendimiento que ADO.NET puro, otras veces fue -10%.

¿Hay alguna forma en que pueda hacer que esas pruebas sean confiables? No tengo una computadora potente con mucha memoria, pero ¿de alguna manera puedo hacer que MS SQL y MySQL o ADO.NET sean lo más consistentes posible durante esas pruebas? ¿Y qué pasa con el recuento de registros, que es más confiable, utiliza una pequeña cantidad de registros y se ejecuta más veces o de otra manera?

Answer 1

¿Has visto ORMBattle.NET? Consulte FAQ there, hay algunas ideas relacionadas con la medición sobrecarga de rendimiento introducido por una herramienta ORM particular. Test suite es open source.

En cuanto a sus resultados:

• Algunas herramientas ORM automáticamente secuencias de sentencias por lotes (es decir, enviar varias sentencias SQL juntos). Si esta característica se implementa bien en ORM, es fácil superar el promedio de ADO.NET entre 2 y 4 veces en las operaciones CRUD, si la prueba ADO.NET no implica el procesamiento por lotes. Las pruebas en ORMBattle.NET prueban ambos casos.
• Mucho depende de cómo se establezcan los límites de las transacciones allí. Por favor, consulte ORMBattle.NET FAQ para más detalles.
• Las pruebas CRUD no son el mejor indicador de rendimiento en absoluto. En general, es muy fácil obtener el máximo rendimiento posible aquí, ya que, en general, RDBMS debe hacer mucho más que ORM en este caso.

P.S. Soy uno de los autores de ORMBattle.NET, así que si está interesado en detalles/posibles contribuciones, puede contactarme directamente (o unirse al ORMBattle.NET Google Groups).

Answer 2

Me gustaría ejecutar la prueba de una duración más larga y con muchas iteraciones más, ya que las pequeñas diferencias promediarían con el tiempo y debería obtener una imagen más clara. Además, asegúrese de eliminar cualquier cosa externa que pueda estar afectando su prueba, como otros procesos en ejecución, memoria libre no suficiente, inicio en frío frente a inicio en caliente, uso de la red, etc.

Además, asegúrese de que su archivo de base de datos y el archivo de registro tiene suficiente espacio libre asignado por lo que no está esperando que el DB haga crecer el archivo durante ciertas pruebas.

Answer 3

Antes que nada, debe averiguar de dónde proviene la varianza. ¿La capa ORM en sí o la base de datos?

Muchas veces la fuente de dicha variación es la base de datos en sí misma. Las bases de datos son sistemas muy complejos, con muchos procesos activos dentro que pueden interactuar con el resultado de las mediciones de rendimiento. Para lograr resultados reproducibles, deberá colocar su base de datos en condiciones de "laboratorio" y asegurarse de que no ocurra nada inesperado. lo que eso significa depende de un proveedor a otro y necesita conocer algunos temas bastante avanzados para poder abordar algo como esto. Por ejemplo, en una base de datos de SQL Server las fuentes típicas de variación son:

• caché frío frente al caché caliente (tanto los datos y procedimientos)
• eventos de registro y la base de datos de crecimiento
• operaciones de mantenimiento que
• fantasma limpieza
• escritura diferida
• puestos de control
• presión de memoria externa