Siguiendo con los artículos relacionados con la optimización para entornos cliente/servidor, queríamos hablarte de una optimización, pero que esta vez no has de realizar tú ya que la hacemos nosotros por ti.

Si recordáis, en el artículo correspondiente hablábamos de la necesidad de controlar el tamaño del mapa que se envía. Citando a Nico en el artículo: “Cuando nos conectamos a un servidor de Velneo éste nos envía la información del mapa de la aplicación, de modo que necesitamos optimizar el tamaño del mapa con el fin de que este traspaso sea lo más rápido posible.”

Continuar leyendo… "Optimización de aplicaciones en Cliente/Servidor (2/6) BIS: Optimizar el tamaño del mapa – Caché de mapas"

Etiquetas: cliente servidor, cliente/servidor, optimización, optimizacion aplicaciones, optimizacion c/s, optimizacion cliente servidor

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
 Continuar leyendo... "Optimización de aplicaciones en Cliente/Servidor (6/6): Efectos negativos no deseados"

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

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.

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

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

Cada vez que realizamos una operación que implique escritura en disco estamos realizando una transacción. Cuando lanzamos procesos que transaccionen nos encontramos con dos casos extremos:
Puede que forcemos muchas transacciones pequeñas, lo que implica:

• Abrir y cerrar cada una de las transacciones, lo que provoca un tiempo de retardo por cada operación (desventaja).
• Dar de alta un registro en el historial del servidor por cada transacción realizada, que también implica retardo (desventaja).
• Bloqueamos pocas fichas, de modo que apenas gastamos memoria en el servidor (ventaja), pero esto no siempre nos interesa. Supongamos, por ejemplo, un proceso en el que para una factura de un cliente realizamos una transacción por cada albarán, y justo cuando hemos facturado la mitad se cae el sistema. ¡Nos queda la otra mitad sin facturar y las transacciones que ya se han realizado no se deshacen! En casos como éste es aconsejable realizar una transacción por cada factura del cliente que englobe todos los albaranes.

Puede que forcemos una sola transacción grande, lo que implica:

• Un gasto considerable de memoria en el servidor (desventaja), ya que éste guarda en memoria las fichas bloqueadas por si hay que deshacer la transacción. Ojo: hay gasto de memoria cuando realizamos bajas o modificaciones, pero no cuando damos altas, ya que en este caso no hay ficha que memorizar por si hay que deshacer la transacción. Caso aparte son aquellas altas que desencadenan actualizaciones, ya que en este caso las fichas modificadas por la actualización sí se guardan en memoria.
• La velocidad a la que se realizan las operaciones es mucho mayor que en el primer caso (ventaja).
• Se genera una sola transacción, de modo que la pérdida de tiempo es mucho menor (ventaja).
• Se bloquean las fichas implicadas en la operación, lo que impide a otros usuarios de la aplicación trabajar con esas fichas (desventaja). No se bloquean todas las fichas a la vez, sino que se van bloqueando según trabajamos con ellas. Es decir, si en una transacción vamos a modificar 1.000 fichas, cuando llega a la 563 habrá bloqueado las primeras 563.

Etiquetas: aplicacion optimizada, optimizacion c/s, transacciones

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.

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

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

Cuando nos conectamos a un servidor de Velneo éste nos envía la información del mapa de la aplicación, de modo que necesitamos optimizar el tamaño del mapa con el fin de que este traspaso sea lo más rápido posible.
En el servidor de aplicaciones podemos instalar tanto un fichero .map como un .vam, pero no pensemos que por instalar el .vam (que ocupa menos) realizamos optimización alguna, ya que el servidor convierte esos archivos a otro archivo .mgz, que es el que realmente nos envía, y que ocupa lo mismo hayamos instalado el .map o el .vam.

. Continuar leyendo… "Optimización de aplicaciones en Cliente/Servidor (2/6): Optimizar el tamaño del mapa"

Etiquetas: optimizacion c/s, optimizacion objetos, tamaño aplicacion

Si hemos desarrollado una aplicación y ésta se ejecuta en arquitectura de red local (utilizando el ejecutor Velneo vRunner) dicha aplicación podrá ser instalada en el Velneo vServer sin realizar por ello ningún tipo de modificación.
Sin embargo, hemos de tener en cuenta una serie de cuestiones que aumentarán el rendimiento de la aplicación (optimizarla) de cara a su instalación en el Velneo vServer, ya que los usuarios pueden estar conectados a la aplicación desde cualquier lugar a través de Internet.

En esta miniserie de recomendaciones para optimizar las aplicaciones en arquitectura Cliente/Servidor, veremos los apartados:

1. Sockets TCP: retardos y optimización
2. Optimizar el tamaño del mapa
3. Elementos que retardan una aplicación
4. Transacciones
5. Optimizaciones para el rendimiento óptimo en ejecución
6. Efectos negativos no deseados

Continuar leyendo… "Optimización de aplicaciones en Cliente/Servidor (1/6): Sockets TCP"

Etiquetas: arquitectura c/s, c/s, optimizacion c/s, socket