Cita:
Empezado por D&W
rolandoj, la configuración que mencioné algún proposito debe tener (mantenimiento por ejemplo), no es la predeterminada, que a como dije, llegué a ella traveseando con la configuración. No vayas a pensar que Firebird es un mal e inepto servidor.
Por otro lado, dices que sospechas que puede ser por la complejidad de la consulta, si tuvieras que darle una escala del 1 al diez, que le darías? Intenta ejecutar la consulta al mismo tiempo en dos o más clientes distintos exactamente al mismo tiempo, que notas en el tiempo de respuesta, hay un margen claro y constante? Por otro lado, los hilos de ejecutan en la misma PC? porque también el problema lo puede causar dbExpress. Haz la prueba que te digo en distintas PC* y fijate en todos los detalles, haz la consulta en parte y ve donde está el cuello de botella.
Por otro lado, te aconsejaría que hagas pruebas con componentes nativos, como IBX o MDO. Puede ser que este tipo de puebas te ayuden a encontrar donde puede estar tu problema.
* Recuerda:
Saludos.
|
Hola,
Muchas gracias por todo el apoyo.
Empiezo diciendote que las pruebas se han hecho con consulta simultánea desde dos PCs distintos a un servidor. Se trata de PCs ubicados en sitios físicamente distintos al servidor y con proveedores de Internet distintos. Claro está, desde ambos PCs, cuando no hay simultaneidad, o se trata de consultas que usan tablas distintas de la Base de Datos, o las mismas; pero en eaquemas relativamente simples (una tablas y pocas condiciones), trabaja bien; incluso, en la propia consulta del problema parece trabajar cuando el nivel de complejidad no está en sus máximos niveles.
Me explico mejor para que visualices la complejidad:
Estas consultas son creadas dinámicamente desde una interfase de usuario que permite escoger los campos a incluír (potencialmente cerca de 100) y las condiciones a colocar (algo así como un SQL guíado; pero el usuario no vé nada que parezca un lenguaje). Las condiciones también pueden ser numerosas; pero no tanto, aunque algunas condiciones pueden tener varios anidamientos. Dependiendo de los campos y las condiciones a incluír, se pueden ir agregando tablas a la consulta, generando bastantes uniones, e incluso otras complejidades de filtros que no pueden incluírse directamente en el Where, todo esto dinámicamente. A lo anterior, agrega que hay algunas consultas adicionales independientes que complementan el Query principal
Darle una calificación puede ser dificil; pero, dado que no se incluyen clausulas Group By o Having, yo lo pondría en 8, máximo 9
En cuanto al cuello de botella, cuando estas consultas se ejecutan solas, pueden tardar entre 10 y 20 segundos. Cuando se presenta el bloqueo, he llegado a esperar 20 minutos y siguen bloqueados. Eso podría hacer pensar en un cerrojo mortal; pero no veo por qué, dado que no hay transacciones explícitas.
Todo esto me lleva a una pregunta adicional. Hay alguna herramienta para monitorear problemas multihilo ?. Porque aquí el inconveniente es que siendo el código tan complejo, conteniendo en sí mismo varias Select, no conozco una manera de poder decir: el bloqueo se presenta al ejecutar la instrucción XXX.
Lo más lógico que pienso en este momento es que ocurre en la consulta más compleja del código; pero, no podría asegurarlo totalmente.
Muchos saludos