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

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

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

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

Ответ 1

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

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

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

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

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

Разработанные приложения:

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

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

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

Ответ 2

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

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

Balázs Hódossy:

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

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

Для 1000-дневного пользователя, сильно используемого, приложение pure vaadin: Server 3 gb 2 ядра Jetty с ulimit до 50000 Postgresql 9 с 50 (используется пул соединений). В качестве части программного обеспечения я также использовал ehcache для кэширования объектов DTO и чистого JDBC.