Память для больших систем в Ваадине

Question

Я работаю в финансовом секторе, и мы собираемся выбрать Vaadin 7 для разработки большой системы тяжелой нагрузки.

Но я немного беспокоюсь о следе памяти Ваадина для больших систем, так как Ваадин держит все состояние в сеансе. Это означает, что для каждого нового пользователя все состояние приложения будет сохранено в памяти, не так ли?
Мы не можем строить монолитную систему - система должна быть масштабируемой и гибкой. Поскольку у нас огромная клиентская база, она должна быть легко настроена и готова к росту.

Не могли бы вы поделиться опытом и возможными обходными решениями, как минимизировать или устранить эти проблемы в Ваадине?

Answer 1

Я думаю, вы должны посмотреть здесь: https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets

Плюс, я нашел следующую информацию по людям, которые управляют Vaadin в производстве.

Балаж Hódossy:

У нас есть бэк-офис системы с более чем 10 000 пользователей. Ежедневный номер пользователя составляет около 3000, но половина из них использует систему 8 часов без выхода из системы. Мы используем Liferay 6.0.5 Tomcat bundle и Vaadin как портсет . Наши два сервера имеют 48 ГБ оперативной памяти, и мы даем кучу Tomcat 24 ГБ. DB получил 18 ГБ, а система остальная. Измерьте кучу на сеанс размер, одновременные пользователи и активность. Больше памяти вызывает больше редко, но дольше полный GC. Мы планируем увеличить количество работников Tomcat и уменьшить кучу. Когда вы измеряете свой сервер, попробуйте добавить немного больше памяти. Если стоимость так важна, как уменьшение , процессор стоит и покупает больше оперативной памяти. В большинстве случаев это ценно с небольшой настройкой.

Пьер-Эммануэль Грос:

В 1000 суточной пользователь heavyly используется, чистое приложение Vaadin: Сервер 3 ГБ 2 ядром Jetty с всеми ограничениями до 50000 Postgresql 9 с 50 пользователей одновременно максимально (соединение пул). В качестве части программного обеспечения я также использовал ehcache для кэширования объектов DTO и чистого JDBC.

Answer 2

Во время разработки нашей продукции мы столкнулись с проблемой большого объема памяти с использованием архитектуры Vaadin по умолчанию.

Архитектура Vaadin основана на компонентах, управляемых событиями. Использование компонентов довольно просто для создания тесно связанного приложения. Причина в том, что компоненты структурированы в иерархию. Это похоже на пирамиду. Более крупное приложение построено; большая пирамида хранится в сеансе для каждого пользователя.

Чтобы значительно сократить выделение памяти, мы создали подход на основе страниц для приложения с комплексной моделью событий на заднем плане с использованием старого управления государственными школами. Он основан на нотации Statechart в формате XML.

В результате сеанс хранит только посещенные страницы во время рабочего процесса пользователя, описанные в конфигурации Statechart. Когда пользователь заканчивает рабочий процесс, все страницы освобождаются для сбора сборщиками мусора.

Чтобы увидеть разницу, мы провели несколько тестов для сравнения памяти, выделенной для пользователя, работающего с приложением.

Приложение, разработанное:

• с сильносвязанным подходом потребляет от 5 до 15 Мб динамической памяти для каждого пользователя
• с рыхлой связью подхода - до 2 Мб

Мы вполне довольны с результатами, поскольку позволяет масштабировать большую систему с использованием 4 ГБ оперативной памяти до 1000-1500 одновременных пользователей на сервер.

Почти забыл. Мы использовали библиотеку Lexaden Web Flow. Это с лицензией Apache.