Tema: En una aplicación java contra el as/400 se van abriendo archivos (files) a medida que se van utilizando y luego de hacerlo, permanecen abiertos hasta cerrar la aplicación.
Detalle: El mecanismo es el siguiente:
* A la primera conexión, se abren los archivos, se prepara y ejecuta la sentencia SQL* Desde la conexión siguiente en adelante, sólo se ejecuta la sentencia SQL sin necesidad de volver a abrir los archivos (y por lo tanto el proceso es más rápido).
En algunos casos se ha presentado la solicitud de tener una opción en GeneXus para permitir forzar el cierre de estos archivos. El problema o argumento es que muchos administradores del AS/400, de todos modos, solicitan que no queden todos estos archivos abiertos, no ven la razón de ello si no están siendo utilizados.
La postura en principio es que no recomendamos que eso se haga, por lo que no está en los planes de ARTech implementar este cambio.
La razón fundamental es la performance.
IBM ha trabajado mucho en este tema (mantener abiertos y reutilizarlos en sucesivas ejecuciones) para mejorar la performance. Incluso existen documentos que guían en cómo programar para que los archivos (ODPs) se mantengan abiertos y sean reutilizables. También se pueden observar trabajos (jobs) que permanecen abiertos (o se abren en forma adelantada) para atender los requerimientos JDBC u ODBC y reducir así los tiempos de conexión a la base de datos. Se pueden ver estos trabajos (QZDASOINIT es el nombre) que normalmente están en el subsistema QSERVER y se arrancan al iniciarse este subsistema aún cuando no exista ningún usuario conectado.
Por otro lado, la experiencia de los clientes grandes como Bantotal (entre otros) es que si los archivos se cierran, la performance se degrada mucho.
Es claro que el costo de esta performance es el consumo de recursos. Es común encontrarse con errores del tipo out of memory en los servidores de servlets y que las aplicaciones dejen de responder con los tiempos esperados, incluso que no lleguen a recibir respuesta del servidor porque este llego al 100%. La recomendación es tratar de optimizar el uso de los recursos y no dejar de usar el pool de conexiones.
En cuanto a esto hay algunas cosas para hacer.
- Hacer un buen tuning del pool de conexiones. Esto depende de la aplicación, y sobretodo de la cantidad de usuarios concurrentes que ésta tenga. Para el iSeries es muy costoso levantar estos jobs (conexiones), por lo que la recomendación es NO tener el tamaño del pool ilimitado, y que las conexiones se creen en el startup del servidor de aplicaciones. Por otra parte, el reciclado de conexiones es mejor que no se habilite, o bien que se habilite con un tiempo grande, de manera que este trabajo de cerrar y abrir las conexiones se de con poca frecuencia.
- Revisar la cantidad de vias configuradas. La cantidad máxima de vías recomendable que se puedan abrir es variable también, depende de la aplicación y también de los usuarios. Es posbile configurar en el AS/400 la cantidad máxima de estas vias, a través de estos comandos:
INSERT INTO QTEMP.QAQQINI (QQPARM, QQVAL) VALUES ('OPEN_CURSOR_THRESHOLD','30');
INSERT INTO QTEMP.QAQQINI (QQPARM, QQVAL) VALUES ('OPEN_CURSOR_CLOSE_COUNT','4')
El primero dice cuantas vias como máximo va a tener
El segundo cuantas va a sacar cuando llegue el límite
En caso de estar activado el reciclaje de conexiones, estas vias deberían disminuir al momento que el pool ve que puede asignárselas a un usuario pero éstas están allí sin ser usadas desde hace X tiempo (RecycleRWMin).
Aplicables a las versiones de GX8 y GX9.
No hay comentarios:
Publicar un comentario