Memory footprint for large systems in Vaadin

Question

I'm working in financial sector and we are about to select Vaadin 7 for development of large heavy load system.

But I'm a bit worried about Vaadin memory footprint for large systems since Vaadin keeps all state in session. It means that for every new user all application state will be stored in memory, won't it?
We cannot aford to build monolithic system - system must be scalable and agile instead. Since we have huge client base it must be easy to customize and ready to grow.

Could anyone please share the experience and possible workarounds how to minimize or eliminate those problems in Vaadin?

How many users is going to use the application? – Ondrej Kvasnovsky Feb 10 '13 at 20:45 — Ondrej Kvasnovsky, Feb 10 '13 at 20:45
More than 20 000 simultaneous users – Yaroslav Ponaryadov Feb 11 '13 at 17:13 — Yaroslav Ponaryadov, Feb 11 '13 at 17:13

score 14 · Answer 1 · answered Feb 16 '13 at 17:23

During the development of our products we faced the problem of large memory footprint using the default Vaadin architecture.

The Vaadin architecture is based on components driven by events. Using components is fairly simple to create a tightly coupled application. The reason is that components are structured into a hierarchy. It's like a pyramid. The larger application is built; the larger pyramid is stored in the session for each user.

In order to significantly reduce the memory allocation we've created a page based approach for the application with a comprehensive event model on the background using the old school state management. It is based on the Statechart notation in XML format.

As the result the session keeps only visited pages during the user workflow, described by the Statechart configuration. When the user finishes the workflow, all the pages are released to be collected by garbage collector.

To see the difference we have done some tests to compare memory allocated for the user working with the application.

The applications developed:

with tightly coupled approach consume from 5 to 15MB of heap per user
with loose-coupled approach - up to 2 MB

We are quite happy with results since it let us scale the large system using 4GB RAM up to 1000-1500 concurrent users per server.

Almost forgot. We used Lexaden Web Flow library. It is with Apache license.

Thank you Aliaksei, sounds great! Hope to contact you to learn more. — Yaroslav Ponaryadov, Feb 17 '13 at 05:48
No problem feel free to contact, also you can try out [enterprise sampler](http://samples.lexaden.com) — Aliaksei Papou, Feb 17 '13 at 14:47

score 9 · Answer 2 · answered Feb 12 '13 at 06:23

I think you should have a look here: https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets

Plus, I have found the following info by people who run Vaadin in production.

Balázs Hódossy:

We have a back office system with more than 10 000 users. The daily user number is about 3000 but half of them use the system 8 hours without logout. We use Liferay 6.0.5 Tomcat bundle and Vaadin as portlet. Our two servers have 48 GB RAM and we give Tomcat 24 GB heap. DB got 18 GB and the system the rest. Measure the heap to the session size, concurrent users, and the activity. More memory cause more rarely but longer full GC. We plan to increase the number of Tomcat workers and reduce the heap. When you measure your server, try to add a little bit more memory. If the cost is so important than decrease the processor cost and buy more RAM. Most of the time it is valuable with a little tuning.

Pierre-Emmanuel Gros:

For 1000 dayly user heavyly used , a pure vaadin application: Server 3 gb 2 core Jetty with ulimit to 50000 Postgresql 9 with 50 concurent users ( a connection pool is used). As software part, I used also ehcache to cache DTO objects,and pure JDBC.

Memory footprint for large systems in Vaadin

2 Answers2