performance - Huella de memoria para grandes sistemas en Vaadin

Question

Estoy trabajando en el sector financiero y estamos a punto de seleccionar Vaadin 7 para el desarrollo de un sistema de carga pesada grande.

Pero estoy un poco preocupado por la huella de memoria de Vaadin para sistemas grandes ya que Vaadin mantiene todo el estado en sesión. Esto significa que para cada nuevo usuario, todo el estado de la aplicación se almacenará en la memoria, ¿no es así?
No podemos permitirnos construir un sistema monolítico; en su lugar, el sistema debe ser escalable y ágil. Dado que tenemos una gran base de clientes, debe ser fácil de personalizar y listo para crecer.

¿Alguien podría compartir la experiencia y las posibles soluciones para minimizar o eliminar esos problemas en Vaadin?

Answer 1

Creo que deberías echar un vistazo aquí: https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets

Además, he encontrado la siguiente información de personas que dirigen Vaadin en producción.

Balázs Hódossy:

Tenemos un sistema de back office con más de 10 000 usuarios. El número de usuario diario es de aproximadamente 3000, pero la mitad de ellos usa el sistema 8 horas sin cerrar sesión. Utilizamos Liferay 6.0.5 Tomcat bundle y Vaadin como portlet. Nuestros dos servidores tienen 48 GB de RAM y entregamos a Tomcat 24 GB. DB consiguió 18 GB y el sistema el resto. Mida el montón al tamaño de la sesión, los usuarios concurrentes y la actividad. Más memoria causa más raramente pero más tiempo completo de GC. Planeamos aumentar el número de trabajadores de Tomcat y reducir el montón. Cuando mida su servidor, intente agregar un poco más de memoria. Si el costo es tan importante, disminuya el costo del procesador y compre más RAM. La mayoría de las veces es valioso con un poco de ajuste.

Pierre-Emmanuel Gros:

Para 1000 usuarios diarios con uso intensivo, una aplicación de vaadin pura: Servidor 3 gb 2 core Jetty con ulimit a 50000 Postgresql 9 con 50 usuarios concurrentes (se utiliza un grupo de conexión). Como parte del software, también utilicé ehcache para almacenar en caché objetos DTO y JDBC puro.

Answer 2

Durante el desarrollo de nuestros productos, enfrentamos el problema de la gran huella de memoria utilizando la arquitectura predeterminada de Vaadin.

La arquitectura de Vaadin se basa en componentes controlados por eventos. Usar componentes es bastante simple para crear una aplicación estrechamente acoplada. La razón es que los componentes están estructurados en una jerarquía. Es como una pirámide. La aplicación más grande está construida; la pirámide más grande se almacena en la sesión para cada usuario.

Con el fin de reducir significativamente la asignación de memoria, hemos creado un enfoque basado en páginas para la aplicación con un modelo de evento integral en segundo plano con la administración del estado de la vieja escuela. Se basa en la notación Statechart en formato XML.

Como resultado, la sesión solo mantiene las páginas visitadas durante el flujo de trabajo del usuario, descritas por la configuración de Statechart. Cuando el usuario finaliza el flujo de trabajo, todas las páginas se liberan para que las recoja el recolector de basura.

Para ver la diferencia, hemos realizado algunas pruebas para comparar la memoria asignada para el usuario que trabaja con la aplicación.

Las aplicaciones desarrolladas:

• con un enfoque estrechamente acoplado consume de 5 a 15 MB de pila por usuario
• con enfoque de acoplamiento suelto - hasta 2 MB

Estamos muy contentos con los resultados, ya que nos permite escalar el gran sistema con 4GB de RAM hasta 1000-1500 usuarios concurrentes por servidor.

Casi olvido. Utilizamos la biblioteca de Lexaden Web Flow . Es con licencia de apache.