miércoles, 13 de mayo de 2009

Mejoras de velocidad (II)

1 comentarios
 
Siguiendo con el tema de las mejoras de velocidad del programa para volúmenes elevados de datos, hemos dado con un fallo heredado de Nuxeo CPS (gestor de contenidos sobre el que se basa KMKey). El fallo estaba relacionado con la gestión de árboles de navegación, y afectaba especialmente el navtree de proyectos y tareas.

Día y medio después de la puesta en funcionamiento de la correción en entorno beta, podemos decir que ha sido un de los mayores avances en el rendimiento de KMKey. En conjunto, desde que se empezaron las mejoras en este sentido, el consumo de RAM se ha dividido por 5, el consumo de CPU ha pasado de un 100% frecuente a no superar el 40% prácticamente nunca, y la velocidad en uso de los usuarios ha mejora espectacularmente.

A falta de mejoras en puntos específicos del programa (no ya de carácter general), podemos asegurar que la nueva versión de KMKey 3 responderá bien en empresas grandes, independientemente del volumen de datos, usando simplemente un servidor de gama media, y teniendo la tranquilidad de disponer de una arquitectura totalmente escalable.

One Response so far.

  1. Gemma says:

    Empiezo a ver que a la práctica todos los mandemientos se resumen en uno: "No crear nunca perfiles de aplicación".

    De hecho si dejamos "Lector de Aplicación" implícito, y "Usuario de Aplicación" para quien pueda crear contenido, el resto puede gestionarse por accesos a los patrones.

    Y si queremos que hay un grupo que vea "todos los expedients del tipo X". Entonces en el patrón X podemos añadir un campo oculto del tipo KMKey Relation, con un default value y un write expression string:docid_de_grupo, y asociado al role Reader.

    De esta forma se pueden ir añadiendo funcionalidades y cada uno sigue viendo lo suyo, y solucionamos el problema que produce añadir un nuevo perfil de aplicación con respecto a los expedientes existentes de otros departamentos.

Leave a Reply