Optimización de aplicaciones en Cliente/Servidor (5/6): Rendimiento óptimo

En nuestras aplicaciones podemos optimizar los procesos forzando que éstos se ejecuten en tercer plano, es decir, en el servidor. Veámoslo con un ejemplo.
A continuación presentamos un proceso sin optimizar:

El origen del proceso es una lista de la tabla CLIENTES y en él se pregunta si queremos o no actualizar los clientes. En caso afirmativo se recorre la lista y se modifica el campo FECHA ALTA.
El proceso se ejecuta en primer plano, es decir, en nuestra máquina. Además,como incluye la función recorrer lista lectura / escritura, escribe en disco.

Esto implica que sólo realice una transacción al recorrer el bucle (si no escribiera en disco realizaría tantas transacciones como registros encontrara, ralentizándose mucho más el proceso).
Podemos optimizar este proceso partiéndolo en dos: uno que incluya el bucle y que se ejecute en tercer plano y otro encargado de lanzar el anterior y que se ejecute en primer plano. Veámoslo:

El proceso que se va a ejecutar en el servidor es el siguiente:

El proceso anterior tiene como origen una lista de la tabla CLIENTES y lo hemos identificado como UPDATE-CLIENTES-OPT-3P.
El proceso encargado de lanzar el anterior es:

Este proceso se ejecuta en primer plano, y en él incluimos la función Ejecutar proceso en la que seleccionamos el proceso UPDATE-CLIENTESOPT-3P, indicando que éste debe lanzarse en modo servidor.

Al montar el proceso de este segundo modo (optimizado) la actualización de la lista se realiza mucho más rápido (diez veces más de media), ya que es el servidor quien la realiza, evitando que haya tráfico de información a través de la red.

Al montar una estructura como la anterior hemos de tener en cuenta que en un proceso en tercer plano no podemos lanzar preguntas, presentar formularios, rejillas… sólo podemos usar la función de procesos Mensaje, que se suele usar para depurar. Sus contenidos se presentarán en la barra de mensajes del servidor de aplicaciones.

Forzar una única transacción

Supongamos un proceso para actualizar las ventas en una lista de clientes y que necesita confirmación por parte del usuario. Éste se compondrá de dos procesos:

Uno lanzador, en primer plano y con origen una lista de la tabla CLIENTES. En él incluiremos la parte que interactúa con el usuario.

                    PROCESO LANZADOR

Otro en tercer plano (ACTUALIZAR-VENTAS-CLIENTES-3P en el proceso anterior) con origen ficha de la tabla CLIENTES, en el que cargamos el histórico de ventas de cada cliente, lo recorremos y realizamos la modificación necesaria en cada registro.

              PROCESO EN TERCER PLANO

Sólo ejecutamos esta última parte en el servidor, ya que necesitamos que, una vez dentro del bucle que recorre los clientes, nos pregunte si queremos actualizar sus ventas en el caso de que se cumpla una condición (en este ejemplo la condición es que pertenezca al aula 8). Para que se presente la pregunta ésta ha de ejecutarse en primer plano.
Ahora bien, aunque parte de este proceso se ejecute en tercer plano, estamos generando una transacción por cada cliente (muchas transacciones pequeñas), lo que ralentiza su ejecución.

Podemos optimizar este proceso forzando una única transacción global para todo el bucle. Para ello haremos que el proceso en primer plano escriba en disco, introduciendo una sentencia que implique modificación en la base de datos. Esta sentencia la incluiremos antes del primer bucle, de modo que todos los subprocesos que vengan después heredarán dicha transacción.
Veámoslo:

             PROCESO OPTIMIZADO

Al introducir la función de proceso Modificar ficha seleccionada estamos forzando a que el proceso escriba en disco, es decir, genere una transacción de la que dependerán todas las que se generaban antes y que vienen después. Fijémonos cómo en el fondo estamos “engañando” a Velneo, ya que la sentencia que acabamos de introducir se encuentra bajo una condición que nunca se va a cumplir (también podríamos haber usado la función Modificar ficha seleccionada, o si el proceso no tuviera origen podríamos usar un Alta directa. La función Modificar variable global no implica escritura en disco).

Veamos otro ejemplo. En este caso se trata de un proceso que importa un fichero ASCII a una base de datos de clientes. El proceso es el que se presenta a continuación:

            IMPORTACION DE CLIENTES

Mediante la función Alta directa (el origen del proceso es ninguno) forzamos a que se genere una única transacción (si no generamos una por cada cliente). A continuación abrimos el fichero y mediante un bucle vamos leyendo sus líneas. El siguiente paso es lanzar un proceso en tercer plano, que es el que realiza el proceso de importación (al ser en tercer plano la importación es mucho más rápida). A este proceso le pasamos los datos leídos en el fichero mediante una variable.

Con esta técnica que acabamos de ver la velocidad de ejecución es mucho mayor, ya que generamos una única transacción y un solo alta en el historial. Ahora bien, tiene sus inconvenientes: al generar una única transacción consumimos mucha memoria en el servidor. Si nos quedamos sin memoria, Windows dará un aviso. Si el motor detecta que se queda sin memoria deshará la transacción, pero puede que no lo detecte y rompa, con lo que se tendrá que deshacer la transacción al arrancar de nuevo el motor.

Otro inconveniente es que todas las fichas que intervienen en el proceso están bloquedas para todos los usuarios. Supongamos, por ejemplo, que en un proceso como el anterior actualizamos el precio de todos los artículos de una gran empresa. Mientras dure el proceso las fichas de los artículos permanecerán bloqueadas, con lo que las ventas estarían paradas ese tiempo porque no podríamos generar tickets de venta (éstos modifican el stock del artículo, pero como las fichas están bloqueadas no se pueden lanzar).

La solución a los problemas anteriores pasa por trocear el proceso en varias transacciones. Veámoslo con el siguiente ejemplo, con el que importamos fotos (portadas) a una base de datos de libros:

Este proceso, que no transacciona, recorre el disco duro buscando extensiones de fotos y memorizando los ficheros en una variable global. Al llegar a 500 fotos llama al proceso IMPORT-PORTADAS-DE-LIBROS-TRN, que es el que realmente realiza la importación y que sí transacciona.

            PROCESO IMPORT-PORTADAS-DE-LIBROS-TRN

Este segundo proceso toma la variable que le hemos pasado, la memoriza en una local, busca todos los ficheros y los importa. A continuación busca el libro, modifica la ficha seleccionada e importa la foto.

Con esta estructura estamos generando una transacción por cada 500 fotos. De este modo la ejecución es rápida, ya que generamos pocas transacciones y a la base de datos le cuesta poco importar 500 fotos. Además bloqueamos menos registros y durante menos tiempo, a lo que hemos de añadir que el gasto en memoria es menor.

Etiquetas: cliente/servidor, optimizacion c/s, rendimiento aplicacion