Optimización de aplicaciones en Cliente/Servidor (3/6): Elementos que retardan una aplicación

Cuando diseñamos una aplicación o trabajamos con ella a través de Internet hay ciertos detalles que hemos de tener en cuenta, ya que ralentizan en gran modo su funcionamiento. Veámoslos:

Visualización de datos obtenidos a través de punteros indirectos
Supongamos una aplicación en la que tenemos las tablas LIBROS, AUTORES y EDITORES, siendo LIBROS histórica de las otras dos. Para presentar en una rejilla de la aplicación una lista de libros con su autor y editor el proceso sería el siguiente: nuestra máquina genera un socket de petición de libros, devolviéndonos el servidor los primeros títulos a presentar (pongamos unos 50 del total, que podrían ser 1.000, por ejemplo). Una vez devueltos estos 50 primeros títulos, se generan un segundo y tercer sockets para pedir los autores y los editores de los títulos devueltos.
En el ejemplo anterior presentamos en una rejilla punteros enlazados a maestro, muy optimizados en Velneo. Ahora bien, en absoluto es aconsejable presentar en una rejilla punteros indirectos, ya que estos enlaces no se encuentran optimizados, de modo que para presentar cada registro de la lista ha de generarse un socket. Si en la rejilla del ejemplo anterior presentáramos un campo capturado mediante un puntero indirecto, como son 1.000 registros tardaría 250 segundos en presentarse (¡más de cuatro minutos!).
Si se trata de un formulario la presentación de datos capturados mediante punteros indirectos también ralentiza la apliación, pero como presentamos uno o pocos registros el efecto se nota menos.

Filtros secuenciales

Supongamos que en una rejilla en la que presentamos artículos queremos quedarnos sólo con aquellos cuyo campo agotado (booleano) tenga valor 1.
Tenemos la opción de Filtrar, pero ésta es desaconsejable ya que filtrando generamos una petición (socket) al servidor, el cual devuelve una primera remesa con 50 o 100 registros que el irunner debe recorrer uno a uno, comprobando el contenido del campo agotado. Terminada esta primera remesa se genera otro socket en el que se piden más registros al servidor y que el irunner debe filtrar… así hasta acabar con toda la lista.
Este proceso es muy lento a través de internet, por lo que es totalmente desaconsejable a no ser que sepamos con total seguridad que el número de registros es muy pequeño. También hemos de saber que cuando filtramos desde las propiedades de una búsqueda el proceso es algo más rápido, ya que el filtrado lo realiza el servidor (tercer plano).
De todos modos, la forma óptima para resolver el problema anterior es mediante la opción de listas Rebuscar, indicando que quite de la lista aquellos registros cuyo campo agotado sea 0. Esto es así ya que Rebuscar trabaja con índices y no va leyendo los registros uno por uno.

Rejillas iniciales donde se muestren objetos
Todos los objetos del contenedor (objetos texto, dibujos, etc.) se tienen que pedir al servidor cada vez que van a ser presentados en una rejilla, de modo que por cada uno se genera un socket. Además no hay caché para los objetos del contenedor. Esto ocasiona que las rejillas en las que presentemos objetos del contenedor se van a ralentizar mucho si las presentamos a través de Internet.

Rejillas con totales
En las rejillas hemos de evitar la introducción de pies, ya que esto fuerza a la lectura de toda la lista para el cálculo del pie.

Condiciones activo / visible y enlaces a hermano
Supongamos un formulario en el que establecemos una condición de activo para un botón (el botón Aceptar, por ejemplo) en las propiedades de un control de edición de un campo enlazado con un puntero indirecto. Como los punteros indirectos no se guardan en la caché de nuestra máquina, cada vez que escribamos sobre el control de edición se generará un socket para que nos devuelva el contenido del campo con el fin de determinar si se cumple la condición. Además, se generarán tantos sockets como condiciones hayamos introducido en el formulario.
Es por esto que las condiciones activo / visible sobre campos capturados con puntero indirecto son totalmente desaconsejables trabajando a través de Internet.
Si el campo es enlazado a maestro o de la propia tabla no tenemos este problema, ya que sí son guardados en la memoria caché de nuestra máquina.

Otro caso parecido al anterior aparece cuando trabajamos con campos enlazados a hermano contiguo. Supongamos un formulario en el que presentamos un campo enlazado a hermano contiguo y en el que tenemos botones Siguiente y Anterior que nos permiten movernos por los hermanos. Sería útil una condición de activo para el botón, de manera que éste se desactivara cuando no hubiera más hermanos (habríamos llegado a los “extremos”), pero verificar esta condición implicaría la generación de un socket cada vez que pulsamos una tecla (al pulsar una tecla se analizan todas las condiciones activo y visible), lo que la hace totalmente desaconsejable cuando trabajamos por Internet.

Etiquetas: aplicacion optimizada, c/s, optimizacion aplicaciones, optimizacion c/s, retardo aplicacion