Optimización de aplicaciones en Cliente/Servidor (6/6): Efectos negativos no deseados

Bucle en el cliente con las búsquedas, historial del servidor

Fijémonos en el siguiente proceso con el que actualizamos las ventas de los clientes entre fechas:

                     PROCESO ACTUALIZAR-VENTAS-CLIENTES-FECHAS NO OPTIMIZADO

El origen del proceso es una lista de la tabla CLIENTES. Éste recorre en solo lectura la lista de clientes, y lanza la búsqueda VENTAS-ENTRE-FECHAS-CLIENTE, que devuelve las ventas de cada cliente y que es alimentada por las variables que hemos modificado antes de lanzarla. A continuación recorre la lista de artículos y modifica la cantidad de cada artículo.
Este proceso genera una sola transacción, pero ocasiona un efecto no deseado:
cada vez que se lanza la búsqueda (tantas veces como clientes contenga la lista) se genera un registro en el historial, lo que disminuye en gran modo el rendimiento del proceso además de cargar el historial con registros no deseados.
¿Cómo salvar este inconveniente? Para evitar este efecto aprovechamos que las búsquedas no son memorizadas en el historial cuando se lanzan en tercer plano, de modo que diseñamos un nuevo proceso, ACTUALIZARVENTAS-CLIENTES-FECHAS-3P, con origen ficha de la tabla CLIENTES. El proceso es el siguiente:

                         PROCESO ACTUALIZAR-VENTAS-CLIENTES-FECHAS-3P

Este proceso hemos de lanzarlo en tercer plano desde principal (ACTUALIZAR-VENTAS-CLIENTES-FECHAS), pero entonces nos encontraremos con otro detalle: estaremos generando tantas transacciones como clientes tenga la lista, de modo que al proceso principal hemos de añadirle una sentencia que implique escritura en disco bajo una condición que no se cumpla. El proceso totalmente optimizado sería:

                PROCESO OPTIMIZADO

Lista de registros en una tabla en memoria
Supongamos un almacén en el que se realiza inventario mediante una pistola inalámbrica conectada al puerto serie de una máquina. De este modo generaremos una lista de registros en una tabla en memoria, pero tenemos un problema: las tablas en memoria no pueden compartirse en arquitectura cliente – servidor, de modo que el motor no tiene acceso a la tabla del Velneo vClient (irunner).
En parte podemos solventar este problema, ya que no se puede compartir una lista entera, pero sí un solo registro de la lista. Veámoslo en el siguiente proceso (no optimizado):

             PROCESO NO OPTIMIZADO

En el proceso anterior, cuyo origen es una lista de una tabla en memoria (los códigos de barras leídos por la pistola), filtramos y ordenamos (permitido en este caso por tratarse de una tabla en memoria). A continuación multipartimos por el artículo, recorremos la lista, modificamos la ficha y disparamos el tubo de ficha que da de alta en la tabla MOV STOCKS la cantidad total a regularizar. De este modo (uno a uno) sí podemos compartir los registros de una tabla en memoria.

El proceso anterior, que se ejecuta en primer plano, va bien si trabajamos en un red local, ¿pero qué ocurriría si el almacén que regulariza se encuentra en remoto? ¿y si además al dar de alta un registro en la tabla MOV STOCKS se disparan contenidos iniciales que evalúan varios punteros? En este caso, al lanzar el tubo de ficha en primer plano se generarían muchos sockets, que retardarían en gran modo la aplicación.
Podemos optimizar el proceso ejecutando en tercer plano el siguiente subproceso con origen ficha de la tabla en memoria:

                   PROCESO-M-INPUT-PISTOL-REGULARIZAR-3P

De este modo la ejecución es mucho más rápida, ya que en tercer plano no se generan todos los sockets generados en primer plano. El proceso optimizado es el siguiente:

           PROCESO OPTIMIZADO

Etiquetas: optimizacion c/s, optimizacion cliente servidor, optimizar aplicacion, registros en tablas