vaadin performance auditing


  1. How does the vaadin team ensure that performance does not degrade from release to release, and how do you set your benchmark for what a base performance should be for something like a new widget?

  2. What is everyone’s take on the theoretical slow down one should experience using vaadin since everything is done on the server side vs doing the same thing on the client side? For example server side validation of a text field would definitely be slower than client side validation, due to the round trips.


Our build / continuous integration system (TeamCity) makes builds every night (and on demand) and runs some 500+ regression tests. The tests are timed, so we get execution time for each test in milliseconds. TeamCity offers some nice statistics and execution time graphs about the tests. In addition, we follow the Jar size, DefaultWidgetSet size, and theme size.

This does not, by itself, ensure that performance never degrades, but at least we’re more aware of any unexpected jumps. Some jumps are expected; for example, the Drag&Drop functionality caused some 20% jump in the size of DefaultWidgetset. It’s unfortunate, but what can you do?

There’s no particular benchmark for the performance of new widgets.

The answer depends mostly on network latency. On a fast network, a 10x jump from some 5 ms to 50 ms would not be noticeable. The problem is, of course, the slow networks, where the slowdown is significant. For example, a typical round-trip time in GPRS or EDGE is around 600 ms, so you’d get a 100x slowdown.

If server-side validation is an issue, you can use, for example, the
CS Validation library
, which offers a client-side validated TextField.

The slowdown also depends on programming practices. If you’re worried about latency, avoid active validation with the immediate mode; only validate on commit clicks, etc.

As you pointed out server-side validation is one of the most common cases where server-side ria is more “chatty” than client-side ria. That said - one must also note that communication is asynchronous and server-side validation request doesn’t block user for continue filling the next field even in the case of really slow networks. Thus real-world use-cases where there is a real difference in the responsiveness of client- and server-side ria are quite few. If one bumps into those use-cases, it is always possible to resolve them by moving those specific cases to client-side.

great thank you all for the input. this is what i was looking for.