Starting spring boot app with Vaadin Flow 14.0.0.rc9 is very slow

Flow
1

I just finished migrating my Spring Boot 2.1.6 / Vaadin 13 app ro 14.0.0.rc9, only using polymer3/npm (using https://vaadin.com/tutorials/migrate-from-bower-to-npm-for-vaadin-14+ as guide, no compatibilityMode).

The app works as expected and also the new Vaadin 14 features work as expected.

However, starting the app (using mvn spring-boot:run is VERY slow. Here the problem:

11:58:41.346 INFO  Initializing Spring embedded WebApplicationContext - org.apache.catalina.core.ContainerBase.[Tomcat]
.[localhost]
.
[/]
11:58:41.346 INFO  Root WebApplicationContext: initialization completed in 1535 ms - org.springframework.web.context.ContextLoader

... now the processed does not show any logging for about a minute, suddenly it continues ....

11:59:48.564 INFO  Starting dev-mode updaters in /home/rmuller/workspace/boot-vaadin folder. - com.vaadin.flow.server.startup.DevModeInitializer
11:59:48.570 INFO  Scanning classes to find frontend configurations and dependencies... - dev-updater
11:59:50.130 INFO  Visited 2166 classes. Took 1559 ms. - dev-updater
11:59:50.159 INFO  Skipping `npm install`. - dev-updater
11:59:50.159 INFO  Copying frontend resources from jar files ... - dev-updater
11:59:50.167 INFO  Visited 9 jar files. Took 7 ms. - dev-updater
11:59:50.167 INFO  Copying project local frontend resources. - com.vaadin.flow.server.frontend.TaskCopyLocalFrontendFiles
11:59:50.169 INFO  Copying frontend directory completed. - com.vaadin.flow.server.frontend.TaskCopyLocalFrontendFiles
11:59:50.170 WARN  Use the './' prefix for files in JAR files: 'flow-component-renderer.js', please update your component. - dev-updater

...

----------------- Frontend compiled successfully. ----------------- - dev-webpack

...

11:59:55.633 INFO  Started Application in 76.236 seconds (JVM running for 77.185)

77 seconds instead of 4 when using Vaadin 13. Seems it is compiling the frontend every time?

What’s going wrong here?

2

Hi Ronald,

Have you tried to use vaadin.whitelisted-packages configuration property? If not, please use it and let us know if there is a difference. You can find more information about it [here]
(https://vaadin.com/docs/v14/flow/spring/tutorial-spring-configuration.html#special-configuration-parameters).

3

Yes, this makes a BIG difference! Thanks.

Startup is now 11 seconds (tried several times). This is still nearly 3 times the startup time of Vaadin 13.

Seems the extra time is caused by the compilation of the frontend, also when no code (actually nothing) is changed:

----------------- Frontend compiled successfully. ----------------- - dev-webpack

Maybe, this is the problem? https://github.com/vaadin/flow/issues/6191

4

Hello Ronald,

May I ask what value you put in the

vaadin.whitelisted-packages=?

on your application.properties?

Thank you.

Ben

5

Ben Izra Dacudao:
Hello Ronald,

May I ask what value you put in the

vaadin.whitelisted-packages=?

on your application.properties?

Yes, in application.properties.
For all classes in package example.myproject.ui and example.myproject.app, this becomes:

vaadin.whitelisted-packages=example/myproject/app,example/myproject/ui

6

Hello Ronald and Medhi,

Thank you for the tip. This is my application.properties on my test application:

vaadin.whitelisted-packages=com/burj/rover/spring

and it worked!

With hot swap enabled the live reload took only:

2019-08-19 14:16:00.215 INFO 14424 — [ restartedMain]
com.burj.rover.spring.Application : Started Application in 3.993 seconds (JVM running for 581.153)

Ben

7

Just tested it with version 14.0.1 (which included the fix for 6191), startup is improved again. However, still much slower than the pre-14 Vaadin Flow versions (on average somewhere between 2 - 3 times).

For non trivial apps i still consider this an issue.

8

Hello,

I have a similar problem now using Vaadin 14.0.0 with Spring Boot (e.g. the standard starter app or a simple app only using the flow components).
The same application itself starts normally (like it did using Vaadin 13), but then there are the following steps that really take too much time:

... dev-updater : Scanning classes to find frontend configurations and dependencies...
... dev-updater : Visited 7144 classes. Took 6957 ms.

… and most of all …

... dev-webpack : Starting webpack-dev-server, port: 58435 dir: C:\development\workspace\...
...
... ----------------- Frontend compiled successfully. -----------------
...
... a.e.p....Application : Started ...Application in 18.609 seconds (JVM running for 19.57)

To me it seems that there are dev-updater and dev-webpack doing much work to compile/transpile the standard Vaadin frontend stuff every time - even if I do not use any custom front end code until now and i did not change anything on the frontend side from one start to the next.

Putting the vaadin.whitelisted-packages property into my dev property file seemed to help as before all took around a minute before, but I see no point in waiting nearly 20 seconds every time i want to start a small standard Vaadin Spring Boot app out of the IDE.

Could it be that it will get better when going to Version 14.0.0.1?
Is this version already officially released?

Or is there a way to tell webpack not to do all of this this everytime I start the application while developing, like it also already skips “npm install” after the first time…?

I remember Vaadin 8 having the same possibility to transpile frontend code from es6 to es5 or similar, but it was possible to let it do this only when using the Maven profile “production-mode” and to switch it off somehow for other cases…

9

Could it be that it will get better when going to Version 14.0.0.1? Is this version already officially released?

Yes, this version (14.0.1) is officially released.

10

Thank you, @Ronald!
I switched to Version 14.0.1 and tried the base starter project with Spring Boot from Vaadin.com as example (download and start as-it-is).
Spoiler: I don’t see any improvement in starting performance compared to 14.0.0.

First time spring-boot:run:

2019-08-21 11:54:54.832  INFO 4120 --- [  restartedMain]
 a.e.evaluation.spring.Application        : Started Application in 269.661 seconds (JVM running for 270.109)

OK, much too long, but includes also the whole “npm install” command for the frontend packages.

second time spring-boot:run:

----------------- Frontend compiled successfully. -----------------
...
Started Application in 12.904 seconds (JVM running for 13.354)

Yes, much faster than at the first time, even though the frontend compilation with webpack is there while I never changed anything, nor in Java code or the frontend.

But then, there is no way to get it faster.
It will take around 13 seconds every time I redo spring-boot:run.

It’s getting much worse when I want to start/debug the application as it is just using the IntelliJ’s “run” command (starting the Application main class…).
This seems to do the same if you look at the console, but every time takes around 32 seconds, and is slow the same every following run / stop and rerun command.
What now I see clearly: There is a really long time gap here between these two log entries in the console:

2019-08-21 13:57:20.377  INFO 11092 --- [  restartedMain]
 o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 912 ms
2019-08-21 13:57:44.276  INFO 11092 --- [  restartedMain]
 c.v.f.server.startup.DevModeInitializer  : Starting dev-mode updaters in C:\development\workspace\local\Java\Vaadin14SpringBootBase folder.

So it seems that in this case it’s not the time that webpack needs for the frontend compilation, but something else is going on at this stage that takes about 24(!) seconds (and about 5 seconds in the case I use the spring-boot:run maven goal).

Well, setting vaadin.whitelisted-packages to the “root” package of the base starter (like mentioned earlier in this thread) really helps in avoiding this time gap - but you have to really reinitialize the whole project, delete all generated files including the npm packages etc. to let the application work properly afterwards.
Doing this, also starting the application the “normal” way the IDE does, in my case I come down to about 13.5 seconds, and sometimes to “just” about 9 seconds for spring-boot:run - which, unfortunately, for some unknown reason I can not use for debugging.

Of course, you can make development easier by switching on hot swap while changing Java code, but you know, hot swap in Spring is not possible on every change.
So it will quite often come to the moment you would have to wait at least 13 seconds (in my case, maybe having a slow PC) to restart the application after a change in the IDE!
That was much faster with Vaadin 13…

P.S.: Maybe we should change this thread’s title to “Starting spring boot app with Vaadin Flow 14 is very slow”

11

I can confirm all your observations. We have a real issues here in terms of developer productivity :frowning:

12

Funny fact:
Switching on the production profile in Maven results to a longer compilation time, but much faster starting time.

So, to me it seems, switching on this profile, at the moment is helping while developing in the IDE, as the application does not search for frontent changes every time it starts - something you never do when you just use the flow api!

That is a little bit weird, as you would expect to be slower in production, but it seems that to include eventual changes the developer makes for frontend costs that much more time…

Just some comparison example times for the Spring Boot Base Starter Application
(assuming NPM install has already been done before you switch profile, because that really takes time):

Maven profile Task Which time Time taken
normal mode spring-boot:run first time 44 seconds
normal mode spring-boot:run other times 11 seconds
normal mode starting for debug first time 13 seconds
normal mode starting for debug other times 12 seconds
production spring-boot:run first time 2 seconds
production spring-boot:run other times 2 seconds
production starting for debug first time 7 seconds
production starting for debug other times 6 seconds
production update/hotswap/restart while debugging other times 5 seconds

Anyway - in addition to the “tricks” already mentioned in this thread, I found out that there is a good possibility to generally make frontend installation/compilation much faster:
When you include the dependency “vaadin-core” instead of “vaadin”.
You have to use “vaadin” only when you would want to take use of all pro tools, too…

13

For me using the whitelist changes nothing.

I use the Eclipse spring boot run, and it takes several minutes to build the app. This was never before using vaadin 12 or 13.
I already changed the dependency vaadin to vaadin core.

This time-problem makes it impossible for me to develop something.

Which step takes so much time? Does the npm install run for each build? :frowning:

14

Hi,

i had the same Problem. But for me it took 600 seconds. I tried

mvn vaadin:build-frontend -X

in my project and the starting process was speeded up to 13 seconds.

Good Luck :slight_smile:

15

Seeing the same startup issue as well. Hesitant to go to Vaadin 14 in no compatibility mode until this gets resolved.

White listing views and components definitely made a big load performance difference.

16

Using Vaadin version 14.0.7 fixed it for me

17

Thank you for the information about Vaadin 14.0.7, @Ines!
Saw also significant performance improvements when upgrading 14.0.8 in one of our small internal applications.

But did anyone have the time to check what that means in detail?

That independent of the used Maven profile (normal/production) and independent of how you start it (with mvn spring-boot:run, with the IDE as spring application or debugging) it is always fast to compile and start up?

That it is not necessary now to go in compatibility mode?
That it is not necessary to do the whitelist thing?

Regards

18

Major startup performance when I upgraded to 14.0.8. I am still running in compatibility mode due to some of the addons used by the app has not transitioned to npm as of yet. Love the upgrade.

19

Allen Pham:
Major startup performance when I upgraded to 14.0.8. I am still running in compatibility mode due to some of the addons used by the app has not transitioned to npm as of yet. Love the upgrade.

unfortunately npm will double / triple your debug time you’ll see :frowning:

20

Umit,

In your opinion, why is it so?