Limit memory consumption of Vaadin session

Question

In Vaadin Flow web apps, the state of the entire user-interface is maintained in the session on the web server, with automatic dynamic generation of the HTML/CSS/JavaScript needed to represent that UI remotely on the web browser client. Depending on the particular app, and the number of users, this can result in a significant amount of memory used on the web container .

Is it possible to limit the amount of memory a session and requests related to it can use?

For example, I would like to limit each user session to one megabyte. This limit should apply to any objects created when handling requests. Is that possible?

Answer 1

It is theoretically possible, but it is not practical.

As far as I am aware, no JVM keeps track of the amount of memory that (say) a thread allocates. So if you wanted to do this, you would build a lot of infrastructure to do that. Here are a couple of theoretical ideas.

• You could use bytecode engineering to inject some code before each new to measure and record the size of the object allocated. You would need to run this across your entire codebase... including any Java SE classes and 3rd-party classes that you app uses.

• You could modify the JVM to record the information itself. For example, you might modify the memory allocator that new uses.

However, both of these are liable be a lot of work to implement, debug and maintain. And both are liable to have significant performance impact.

---

It is not clear to me why you would need this... as a general thing. If you have a problem with the memory usage of particular types of requests, then it would be simpler for the request code itself to keep tabs on how big the request data structures are getting. When the data structures get too large, the request could "abort" itself.

Answer 2

As the correct Answer by Stephen C explains, there is no simple automatic approach to limiting or managing the memory used in Java.

Given the nature of Vaadin Flow web apps, a large amounts of memory may be consumed on the server for user sessions containing all the state of each user's user-interface.

Reduce memory usage of your codebase

The first step is to examine your code base.

Do you have data replicated across users that could instead be shared across users in a thread-safe manner? Do you have cached data not often used that could instead be retrieved again from its source (database, web services call)? Do you cache parts of the UI not currently onscreen that could instead be instantiated again later when needed?

More RAM

Next step is to simply add more memory to your web server.

Buying RAM is much cheaper than paying for the time of programmers and sysadmins. And so simple to just drop in more stocks of memory.

Multiple web servers

The next step after that is horizontal scaling: Use multiple web servers.

With load balancers you can spread the user load across servers fairly. And “sticky” sessions can be used to direct further user interactions to the same server to continue a session.

Of course, this horizontal scaling approach is more complicated. But this approach is commonly done in the industry, and well-understood.

Vaadin Fusion

Another programming step could involve refactoring app to build parts of your app using Vaadin Fusion .

Instead of your app being driven from the server as with Vaadin Flow, Fusion is focused on web components running in the browser. Instead of writing in pure Java, you write in TypeScript , a superset of JavaScript. Fusion can make calls into Vaadin Flow server as needed to access data and services there.

Consulting

The Vaadin Ltd company sells consulting services, as do others, to assist with any of these steps.

Session serialization

Be aware that without taking these steps, when running low on memory, some web containers such as Apache Tomcat will serialize sessions to disk to purge them from memory temporarily.

This can result in poor performance if the human users are actively still engaged with those sessions. But the more serious problem is that all the objects in your entire sessions must be serializable . And you must code for reconnecting database connections, etc. If supporting such serialization is not feasible, you likely can turn off this serialize-sessions-on-low-memory feature of the web server. But then your web server will suffer when running out of memory with no such recourse available.