Over the past months, I have created several applications with Vaadin and always been a little worried about scalability. I have read through the Vaadin blogs and the recent talk about the MovieTicket system as well as followed discussion on Tomcat servlet deployment on resource requirements and consumptions.
The most recent addition, an online tutorial where students can interactively work with Dijkstra’s algorithm, turns out to be an issue. With a few thousand lines of code and internally using Jung graph library and Mysql connection (the WAR is 12 MB ), already two dozen simultaneous connections are requiring a significant amount of memory (see attachment). I did scan for memory leaks and orphaned sessions, but this does not seem to be the issue.
Can people share their experiences on resource consumption? What are typical session sizes? What are best practices to keep the utilization low (besides just using as few elements as possible inside the class - in my case one dozen textfields)?
The next project is designed for concurrent use of a few hundred people, so based on these experiences do I need to plan for a large server (8GB-16GB of RAM) or is this just an abnormal application behavior?
I don’t have the “proper” memory numbers and consumption in my head, so I’ll leave that for someone else. However I’d recommend you to have a look at your tomcat instance with a proper profiling tool, e.g. VisualVM which is bundled with java (JDK at least, perhaps even JRE)
That way you can quite easily get a little closer glimpse at what phase of application usage memory is reserved and if memory is garbage collected and freed in decent time after user session ends or if you have some memory leaks.
Was there any strange behavior in the application because of it being out of memory? In my experiences, a JVM will take up all memory given to it before the garbage collector will start strolling the lanes. If you think about it, it makes sense too, why to GC when you still have new memory to allocate. You save some CPU cycles by not having to clean up all the time. If there is no symptoms I’d suggest that you just limit the amount of memory available. If the app breaks down then it is a completely different story and you should profile it as Jonas said.
Not quite. The garbage collector typically fires before Java grabs more memory for the OS (i.e. when -Xms is smaller than -Xmx). If you know your application will reach -Xmx anyway in its stable mode, then changing the Java values to make both values match will save you garbage collections.
I would tend to think that in most instances Vaadin is not the culprit. Graph structures and XML DOMS, however, do tend to be memory hogs. I’ve seen flat files of 4K turn into 5Megs of data structure junk in memory.
Thank you all for your answers. I did install VisualVM (like Vaadin - what a gem) and profiled the application with a number of sessions.
First of all (as somebody as asked it), when I previously ran out of memory, the server began to swap in and out which essentially consumed most of its cycles that even logging in by SSH became an issue. The box is now upgraded to 4GB of RAM, and it now handles the traffic smoothly (so far only a max of 25 students concurrently used it).
What I observed from VisualVM was essentially normal behavior in my opinion: After a session was initiated, I see an increase in heap size of about 10-15 MB which over time shrinks again. Garbage collection is triggered about every 5-10 seconds if the used heap size is approaching the total size of the heap.
So far so good. I looked into the root cause for this sawtooth behavior of the used heap size. It turns out there there’s a huge number of char being allocated and immediately garbage collected every few second (this is on the order of a few MB/person/instance). In my source code I don’t explicitly use any char
. The heap dump of these char showed the following text (an excerpt):
UI is typically eating from 50k to few hundred k. For a large application couple of megs might not be out of question. That said, it is really easy to store too much data layer state to session if not careful.
