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.
@ssmusoke which version of the platform are you using? And can you provide the number (or a list) of modules.
@mseaton’s suggestions are on point. Our current approach on handling module startup is inefficient and doesn’t scale well. We are going to need to reinvent things a bit to support OpenMRS 3 deployment, which requires a discreet build step. I’m hoping we can leverage some ideas @raff has for foregoing our hot-swapping of modules in exchange for a backwards-compatible build process that could vastly improve startup times, reduce complexity, and improve the developer experience.
Ouch that is a long list. Not a helpful comment but out of curiosity @ssmusoke, roughly what % of these modules do you think are basically unnecessary but are kicking around due to tricky dependencies (if any)?
(Not meaning to be rude, I just remember you making a comment to this effect a while ago.)
Yeah, this is a continual problem… generally with our distributions startup time gets slower and slower while refreshing the context, and eventually we get sick of it and spend some time digging into it and speeding things up (which is never easy) and share a couple minutes off startup… and then, a few yesrs go by, and it slows down again.
Also, there’s the long-time issue where @Autowiring within services can really slow thing down for some reason we’ve never figured out. Any of the OpenMRS module should hopefully not be doing this, but worth checking out any of the custom modules. I tried to find the original link for this but couldn’t, but here’s one that talks about it: