Vaadin Resources / Slowliness

General
1

Hi, my team mates are worried about the performance when switching to Vaadin. Currently the Portal runs in PHP which is not server side rendering or?

We will deploy in Azure, now i want to make some examples and show that vaadin is not slow.

The portal will have max 100 users at the same time. So i think an Azure Service with 4GB of RAM should make it.

Does anyone has an idea of how i could compare a PHP App and a Vaadin App to find possible Memory/Slowliness issues or if not present, to proof that vaadin would be a great choice?

The biggest try would be to have a grid with a huge dataset or which component could be the most slow component?

At the end the RAM usage would have the biggest impact in Vaadin peroformance or? When i load a lot of data, they are stored in the server session. I dont know PHP so its hard to make a comparison

2

PHP is typically server-side rendering (although you can write client-side rendering code with JavaScript in PHP). Vaadin is not server-side rendering, but Vaadin Flow apps have a stateful server.

3

Can you tell a bit more about what your app will be doing? And creating a prototyp that will cover your uses cases will help

4

Hi,

it will do no huge calculations or so. 99% will be getting data from DB and updateing data in the db.

Yesterday i added 4 grids into a view and set them 100.000 items and set the pagesize of the grid to 100.000 to disable the ajax lazy loading. By opening the view it loaded 400.000 lines, for sure this take some seconds, because it must fetch the data, but this is not a problem of vaadin, its the SQL query.

But it eats up all available jvm RAM when i opened this view 10 times. This will be an plus for PHP, right? It will send all the data to the user and the server forgets it immediately.

5

You can use lazy loading in a Grid so you won’t need to load all that data in memory. Grid | Components | Vaadin Docs

6

Hi Olli, yes i know. But i want to show my team mates,that even it loads heavy data the view is still not lagging

7

In your previous message, you said:

But it eats up all available jvm RAM when i opened this view 10 times.

If you implement lazy data loading from the database with Vaadin, it will not eat all available RAM. A lazy-loading Grid can potentially handle an infinite number of rows (or at least up to some very high number like maximum integer value) with a fixed memory footprint. PHP, on the other hand, needs to load all of the rows in the table into memory to generate the table, so it will run out of memory sooner or later.

1 Like
8

Thank you, when you talk about lazy loading you mean a DataProvider who fetch the data paginated from the database or you mean that the frontend only get 50 rows and when scrolling ajax request next 50?

So currently i load 100.000 objects and set them to the grid, so they are build in the JVM. Logically that the jvm needs to consume space to hold this 100.000 items

i should need pagination i know, but like mentioned, i want to show, that a view with huuuuuge amount of data is not getting slower. Its the “backend” which needs to be improved in order to handle the data in a resource friendly way

9

Like in that link I posted above, lazy-loading with Grid usually refers to loading data from the database (or a similar backend). This means you won’t have to load the entire 100000 objects into memory, as you’re only fetching the items the Grid is currently showing in the browser, plus some buffer for smooth scrolling. The <vaadin-grid> web component in the browser has a smart scrolling functionality, so it only loads the rows it needs to show, which means it both initializes quickly (it doesn’t need all load 100 000 rows) and if you suddenly jump into row 75 000 or 15 000, it can fetch a small batch of items very fast - and all of this without consuming excessive browser or server memory. There’s no sense in loading all 100 000 items because no display can show them all at once. If you’re concerned about scrolling performance, I recommend you test it with proper lazy loading.

10

I think you miss understand my concern of ignoring lazy loading.

Lets imagein there is a Service :

DatabaseService.fetchData(); <this Method gives me 100.000 Objects od Person.class

This Service is not mine, i dont have any influence to it, i need to use it how it is (returning 100.000 Objects). I can not change the SQL behind it or what ever, i must work with this 1000.000er Object List.

In our PHP Portal, this is no problem. Now i want to show y team mates that vaadin also can handle this amount of data (even if its senseless to show 100.000 rows at a time)

List<Person> persons = databaseService.fetchData();
grid.setItems(persons)
gris.setPageSize(100_000)

I have the 100.000 Persons in my list and in RAM. That has nothing to do with vaadin.

When i now open the frontend, vaadin show all the rows, which work fine.

Now i want to have any kind of comparison with php. One disadvantage in this case i see is, that java keeps the 100.000 items in memory, while php does not.

11

Yes, in that case, you definitely need a better database service that allows specifying which items you want to load.

12

So now the question is: Does Vaadin’s server session grows as well with those amount of data or is that only the “natural java jvm” behaviour which holds the data? What kind of data are going to be saved in the vaadin session on the server?

13

You can still do lazy loading if you can’t touch that (badly implemented) service class. Just don’t store a reference to the whole set and re-fetch it in the callback. An example:

    VGrid<Person> myGrid = new VGrid<>();
    myGrid.setItems(query -> {
        List<Person> list = databaseService.fetchData();
        return list.subList(
                query.getOffset(),
                Math.min(list.size(), query.getOffset() + query.getLimit())
        ).stream();
    });

This way memory is consumed only for a short period of time and then GC’d. Just like with PHP.

But yes, as Olli mentioned, for better scalability, with both PHP and Java, use some kind of paging/lazy loading. Fetching the whole table from the backend on each request wastes resources, both CPU and memory, both in the database and in the server (whateve the technology).

3 Likes