As a rule of thumb a typical Vaadin application scales up to 10 000 concurrent users per server. See below for a list of factors that affect scalability and how they could be tackled in Vaadin's case.
An application's scalability is affected by three things: the amount of server resources the application consumes per user, the number of concurrent users that are using the application at peak time and the number of servers.
Server-resources boil down to CPU usage, memory usage and I/O as the biggest bottlenecks for scalability.
|Bottleneck||How Vaadin works|
|Processing power||As Vaadin is a UI layer framework, it does not affect your back-end layer processing power. Save for the Application Server using CPU to create the HTTP Session, vaadin uses processing power only marginally.|
|Lock contention||Vaadin does not use any global locking that might cause concurrency overhead with multiple threads.|
|Session size||Vaadin stores the state of the user interface on the server-side in the HTTP session. The size of the session fully depends on the amount of state (e.g. views) and business data that is stored in the application, ranging from 50kb to 1000kb per concurrent user, depending on the amount of business data that is stored in the session. Memory use is rarely a bottleneck for a properly designed application. See below for tips on optimizing the session size.|
|Back-end layer||Vaadin does not add overhead for the backend layer. The key is to not reference more business data in the session than is required. E.g. fetching data into a BeanItemContainer instead of a lazy loading container will increase your memory consuption. Vaadin is agnostic about how much back-end data is stored in the session.|
|Database access and file I/O||The database layer is most typically the first pain point when writing scalable applications, especially when using a centralized SQL database. A benefit of the Vaadin way of keeping the application state in the session is actually that it helps caching backend data that would otherwise need to be fetched from the database every time.|
|Number of open TCP connections||If using Vaadin with a constantly open push connection (like long polling or WebSocket), the number of allowed connections will most likely be your first bottleneck. A typical file descriptor limit on Linux is 400 000 which limits the number of connections. Ensure that the application server, front proxy, and the OS alike can handle enough concurrent connections.|
|Network bandwidth||Vaadin uses HTTP and XHR as the default communication mechanism. Vaadin's communication stack is optimized to only send deltas, so that only state changes are communicated over the network from both client to server and server to client. Multiple state changes in the UI are combined to batches to avoid typical "AJAX chattiness". With applications that are used for a longer period of time, this most often consumes less bandwidth than traditional web applications.|
|Middleware||Middleware, such as MQ, JPA and ESBs, in general add complexity to your technology stack that limits the throughput to your application. Vaadin however is agnostic about your technology stack and does not limit scalability itself.|
Tips for achieving highly scalable applications
Most often scalability issues relate to a slow backend or database layer. Vaadin affects scalability mostly through its session size. A rule of thumb for a Vaadin applications is that the session size is somewhere between 50kb and 1000kb depending on the amount of views you keep in the session and the amount of business data populated e.g into a component's memory. On a very small server installation with only 8Gb of memory, this would account for some 8 000 concurrent users using your Vaadin application at the same time. To scale this up, use a larger server or balance the traffic between servers as described below.
- Avoid long queries that consume CPU
- Avoid N+1 queries, use proper lazy loading for ManyToMany, ElementCollection and OneToMany JPA relations
- Use a tool like XRebel, proper logging or a profiler to spot bottlenecks in your application. Also use properly sized test data during development.
- Keep session size to a minimum to minimize memory footprint per user
- Lazy load the views of your application and make sure they can be GC:ed when on other views.
- Keep a sane amount of components and data on views
- If you have large data tables on your views, consider using lazy loading containers.
- Use clustering when needed
- If your service can't fit in one server, Vaadin applications are easy to cluster. For best performance, use "sticky sessions", even if you share your sessions in your cluster for high availability (HA). This way the session can most often be quickly found from the application server's memory. With sticky sessions your session also doesn't need to be serializable, which might help developing your application, but you'll need serializable sessions for HA services.
- Verify your application scales well using stress-testing tools: