I feel your pain @ssmusoke and would also love to see us all put our heads together to see if we can improve this. In my experience I’ve never found much difference in the size of the database - it is interesting if you find that your startup time is considerably slower when you are connecting to a DB with millions of records vs. a dev or test instance with far fewer. I’d probably take that as a separate issue to investigate on it’s own.
Spring application context startup and bean instantiation/wiring is generally the biggest culprit I believe, and I agree that it would be more helpful to have some information being spit into the logs that is showing this process at work rather than just sitting there at those INFO statements for many minutes (or hours!). It would be interesting if someone could identify some logging levels that could be enabled (eg. what classes/packages at what log levels) and would provide enough, but not too much, logging in this area to be able to gain some insights into what is taking so long. Starting up in a Profiler session is another approach that will likely gain insights, though that takes some experience to be able to interpret, and I’m no expert at it.
In the short term, what is “easy” and would be interesting and hopefully instructive to look at, would be for you to do an exercise like the following:
-
Install a brand new SDK instance of ugandaemr, and move all modules out of the modules directory and into some temporary location (eg. modules-bak).
-
Start up the server and note the time it takes to complete (eg. server listening on port 8080)
-
Add modules back in one-by-one, in proper dependency order. Each time you add a module in, repeat step 2
Once you have done this with all of the modules, have a look at the results, and see if it identifies any particular modules that, when added, caused the spring startup time to dramatically increase. Report back here on the results - I’d find them very interesting to see, and we can continue brainstorming from there.
Thoughts? Mike