Transacciones en Zeos. Conviene una por Conexión ?

[rolandoj]

Empezado por Casimiro Notevi

De todas formas, pienso que antes de darle tantas vueltas al tema, lo que deberías hacer es una prueba, creas un programita que realice consultas, modificaciones,etc. con códigos aleatorios y lo ejecutas tantas veces como clientes piensas que puedes tener trabajando, vas incrementando "el ataque" al servidor y vas comprobando cómo se comporta este último, así te puedes quedar tranquilo... o no.

Yo siempre hago simulaciones de los sistemas para ver si van a trabajar bien, tanto en conexiones, tamaño de base de datos, memoria, etc.
Estas pruebas las hago con muchísima más carga que la máxima esperada para el sistema en cuestión, así puedo estar seguro de que responderá adecuadamente.
Una de las últimas pruebas fue lanzar 1000 conexiones simultáneas a un servidor suse linux con firebird classicserver, realizaba selects, updates y deletes aleatorios en distintas tablas de una BD con más de 100 Gigas de tamaño. La prueba se superó con éxito.
A partir de ahí estábamos seguros que el proyecto iba bien encaminado y nos pudimos concentrar en seguir trabajando sabiendo que no habría problema.

Hola Casimiro,

En general, el hacer simulaciones es una opción válida y recomendable. De hecho, y hasta cierto punto nosotros también las hacemos; pero, en mi caso hay dos problemas:

1. No conocemos ni el motor ni los equipos en que se ejecutaran los aplicativos. Eso sería lo de menos porque en últimas podríamos trabajar con equipos y motores representativos; pero, igual no resulta una prueba tan diciente.

2. El gran problema es la dificultad de armar una simulación razonable porque aquí se trata de un sistema muy complejo, con muchísimas tablas de características muy disimiles, relaciones entre ellas, y procesos mezclados, que no permiten facilmente identificar los cuellos de botella más críticos. Por eso es que he procurado indagar en la parte teórica de los rendimientos.

Como sea, creo que ya no hay mucho más que podamos analizar en la parte teórica y ya toca empezar a hacer pruebas.

Saludos

[rolandoj]

Empezado por Casimiro Notevi

Sí que lo hay, se ha comentado en diversas ocasiones, aunque lo más a mano que tengo es esta comparativa del que hice un pdf.

También puedes ver este hilo.

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

[[mightydragonlor]]

Empezado por rolandoj

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

Como dije antes, esto no se nota, a menos que hagas transacciones intensivas, de mas de 10.000, además, ZEOS tiene que hacer Parser de todas las consultas para identificar si es correcta o no, a parte de las múltiples interfaces a los diversos motores, cosa que ADO y BDE no hacen, por otro lado ZConnection1.ExecuteDirect(), ejecuta una instrucción SQL sin pasar por todo el proceso y es por mucho mas rápida a las normales, así que siempre tienes la opción, dependiendo del proceso que hagas, como en vez de generar 1000 inserts con 1000 commits, generas un sólo commit para los 1000 inserts y podrás ver una diferencia grande en desempeño.

Saludos.