Skip to content

Conversation

@rkorytkowski
Copy link
Member

@rkorytkowski rkorytkowski commented Dec 16, 2025

Description of what I changed

Issue I worked on

see https://issues.openmrs.org/browse/TRUNK-6418

Checklist: I completed these to help reviewers :)

  • My IDE is configured to follow the code style of this project.

    No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

  • I have added tests to cover my changes. (If you refactored
    existing code that was well tested you do not have to add tests)

    No? -> write tests and add them to this commit git add . && git commit --amend

  • I ran mvn clean package right before creating this pull request and
    added all formatting changes to my commit.

    No? -> execute above command

  • All new and existing tests passed.

    No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

  • My pull request is based on the latest changes of the master branch.

    No? Unsure? -> execute command git pull --rebase upstream master

The reported startup performance improvements:

[INFO] Running org.openmrs.StartupPerformanceIT
INFO - StartupPerformanceIT.compareStartupPerformance(187) |2025-12-16T14:43:27,261| openmrs/openmrs-platform:2.8.x installed in 37238ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:43:47,312| openmrs/openmrs-platform:2.8.x started up in 19628ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:44:06,531| openmrs/openmrs-platform:2.8.x started up in 18839ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:44:26,200| openmrs/openmrs-platform:2.8.x started up in 19189ms
INFO - StartupPerformanceIT.compareStartupPerformance(205) |2025-12-16T14:44:50,716| openmrs/openmrs-platform:2.9.x upgraded in 19805ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:45:12,174| openmrs/openmrs-platform:2.9.x started up in 17991ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:45:34,583| openmrs/openmrs-platform:2.9.x started up in 19075ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:45:57,009| openmrs/openmrs-platform:2.9.x started up in 19070ms
INFO - StartupPerformanceIT.compareStartupPerformance(218) |2025-12-16T14:45:57,244| openmrs/openmrs-platform:2.8.x started up on average in 19218ms, while openmrs/openmrs-platform:2.9.x started up in 18712ms, which is 3% (506ms) faster
INFO - StartupPerformanceIT.compareStartupPerformance(187) |2025-12-16T14:47:51,843| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo installed in 112783ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:48:34,145| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 41846ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:49:16,272| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 41675ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:49:58,385| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 41634ms
INFO - StartupPerformanceIT.compareStartupPerformance(205) |2025-12-16T14:50:46,229| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo upgraded in 43130ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:51:28,545| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 39120ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:52:09,364| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 37354ms
INFO - StartupPerformanceIT.measureMeanStartupTime(233) |2025-12-16T14:52:50,211| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 37521ms
INFO - StartupPerformanceIT.compareStartupPerformance(218) |2025-12-16T14:52:50,472| openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up on average in 41718ms, while openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo started up in 37998ms, which is 9% (3720ms) faster
[WARNING] Tests run: 3, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 611.2 s -- in org.openmrs.StartupPerformanceIT

They will be even more significant for implementations having longer history of upgrades as we are only testing against a system upgraded only once from 2.8.x to 2.9.x.

@rkorytkowski rkorytkowski changed the title TRUNK-6418 TRUNK-6418 Run liquibase checks and data imports only when version of core or modules changes Dec 16, 2025
@rkorytkowski rkorytkowski requested a review from dkayiwa December 16, 2025 13:56
@rkorytkowski
Copy link
Member Author

@dkayiwa @IamMujuziMoses I'd appreciate yet another round of reviews, thanks!

// GP may be null, but the session may contain an unflushed gp so
// we will do a final check with session.get below. It may happen,
// if flush is set to manual and running in a larger transaction.
return gp;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One test annotated with @StartModule was failing because of this. In general I think we have an issue with case-insensitive primary keys here. Session.get is using an L1 cache that is always case sensitive and we may run into strange errors, because of how we handle GPs. I will open an issue for that with a failing test case.

if (useInMemoryDatabase()) {
runtimeProperties.setProperty(Environment.DIALECT, H2Dialect.class.getName());
String url = "jdbc:h2:mem:openmrs;DB_CLOSE_DELAY=30;LOCK_TIMEOUT=10000";
String url = "jdbc:h2:mem:openmrs;DB_CLOSE_DELAY=30;LOCK_TIMEOUT=10000;IGNORECASE=TRUE";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to match what is in jupiter/BaseContextSensitiveTest

@IamMujuziMoses
Copy link
Contributor

LGTM 👍🏾

// 2.9.x should start at least 10% faster than 2.8.x
compareStartupPerformance("openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo",
"openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo", Duration.ofSeconds(0));
"openmrs/openmrs-reference-application-3-backend:3.6.x-no-demo", -10);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expected performance improvement to be 10% faster.

@dkayiwa
Copy link
Member

dkayiwa commented Dec 18, 2025

@rkorytkowski did you get a chance to run this with O3?

@rkorytkowski
Copy link
Member Author

@dkayiwa absolutely. Ran it with docker compose as well as it is running inside Startup performance test.

@dkayiwa
Copy link
Member

dkayiwa commented Dec 18, 2025

@rkorytkowski i am assuming that you simply changed this https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/distro/pom.xml#L26 to 2.9.0-SNAPSHOT and then docker compose build, after which you did a docker compose run. Did you do anything else?

@rkorytkowski
Copy link
Member Author

rkorytkowski commented Dec 19, 2025

No, it's not enough. Docker build doesn't have access to your local maven repo so it fetches 2.9.0-SNAPSHOT from OpenMRS maven repo. In order to test your locally build war you need to add to docker-compose.override.yml something like this:

    volumes:
      - /Users/rafal/workspace/openmrs-core/webapp/target/openmrs.war:/openmrs/distribution/openmrs_core/openmrs.war

/**
* Ask Liquibase if it needs to do any updates.
* Determine if Liquibase updates are required. If OpenMRS Core version did not change, then do not run any checks
* unless <b>force.setup</b> runtime property is set to <b>true</b>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about renaming this setting to something else? When i look at force.setup i do not find it easy to relate it to Run liquibase checks and data imports only when version of core or modules changes 😊

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is to run liquibase checks and data imports regardless if versions change or not. Any suggestions for naming?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will rename the property to optimized.startup and make it true by default. To force running liquibase you would have to set it to false. I will re-use the same property in TRUNK-6509.

@dkayiwa
Copy link
Member

dkayiwa commented Dec 19, 2025

Thanks @rkorytkowski for the clarification. 😊

Where should i expect the 10% improvement in startup time? For i have run O3 on core 2.8.2 and core 2.9.0 with your changes. They both take around 30 seconds to start. I am using docker for both.

@dkayiwa
Copy link
Member

dkayiwa commented Dec 19, 2025

I have just remembered that i need to create a setting named force.setup and set its value to true. Let me do that and test again.

@rkorytkowski
Copy link
Member Author

Hi @dkayiwa, force.setup is only needed for development when you want to force running liquibase without version change. Do you see any improvements reported when running mvn clean install -Pperformance-test -Pskip-default-test? It might be that your CPU is so fast that the difference is lower than 10%. Also please note that container startup times (docker engine) differ and we need to measure the application startup time alone. For accurate results please look in logs for INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [39148] milliseconds

@dkayiwa
Copy link
Member

dkayiwa commented Jan 5, 2026

@rkorytkowski how long does mvn clean install -Pperformance-test -Pskip-default-test take to run to completion on your laptop?

@dkayiwa
Copy link
Member

dkayiwa commented Jan 5, 2026

Here is the full log: https://pastebin.com/uvG6mESY
I am on the rkorytkowski-TRUNK-6418 branch with the changes in this pull request

@rkorytkowski
Copy link
Member Author

@dkayiwa see my results above... Your results are intriguing. Did you do/run anything else during execution? Even if I run a youtube video during execution it will slow down the build so you need to make sure your machine is focused on testing...

IamMujuziMoses and others added 2 commits January 7, 2026 12:16
…f core or modules changes

(cherry picked from commit 4723e71c3f39a6467ab6f4060dab42a694cd1a68)
@rkorytkowski
Copy link
Member Author

@dkayiwa could we get this merged to see if it improves things when running performance tests with github actions? We can revert if it's not...

@dkayiwa
Copy link
Member

dkayiwa commented Jan 7, 2026

No problem. Let me merge it right away as i continue testing it out.

@dkayiwa dkayiwa merged commit 55cf1c5 into openmrs:2.9.x Jan 7, 2026
10 checks passed
@dkayiwa
Copy link
Member

dkayiwa commented Jan 8, 2026

@rkorytkowski now i am getting this when i run mvn clean install -Pperformance-test -Pskip-default-test on the 2.9.x branch: https://pastebin.com/8Vc1k6is

@dkayiwa
Copy link
Member

dkayiwa commented Jan 8, 2026

Just in case you need it, here is the full log: https://pastebin.com/CRNcA8jj

@dkayiwa
Copy link
Member

dkayiwa commented Jan 8, 2026

Interesting that i have just run it again and it passed with this: https://pastebin.com/kVM1FRNr

@rkorytkowski
Copy link
Member Author

Yes, I fixed it in 542ec4c

I wonder why it's not improving on your machine. GHA consistently reports improvement as well as my machine. It is also more than 2x slower in your tests. It must be something specific to your setup... Let me create a branch of O3 with 2.9.x so you can run it outside of tests and see how it performs...

@rkorytkowski
Copy link
Member Author

rkorytkowski commented Jan 9, 2026

@dkayiwa Could you please run "TAG=3.6.x-core-2.9 docker compose up" from openmrs-distro-referenceapplication? How does it perform compared to "TAG=3.6.x docker compose up"?

@rkorytkowski
Copy link
Member Author

Also please note that consecutive "TAG=3.6.x-core-2.9 docker compose up" startups are even faster thanks to using already expanded war (and soon jars).

rkorytkowski added a commit that referenced this pull request Jan 12, 2026
… core or modules changes (#5603)

* TRUNK-6418: Run liquibase checks and data imports only when version of core or modules changes

(cherry picked from commit 4723e71c3f39a6467ab6f4060dab42a694cd1a68)

* TRUNK-6418: Follow up adjustments

---------

Co-authored-by: IamMujuziMoses <[email protected]>
(cherry picked from commit 55cf1c5)
vimla01 pushed a commit to vimla01/openmrs-core that referenced this pull request Jan 12, 2026
… core or modules changes (openmrs#5603)

* TRUNK-6418: Run liquibase checks and data imports only when version of core or modules changes

(cherry picked from commit 4723e71c3f39a6467ab6f4060dab42a694cd1a68)

* TRUNK-6418: Follow up adjustments

---------

Co-authored-by: IamMujuziMoses <[email protected]>
(cherry picked from commit 55cf1c5)
Chinmay7070 pushed a commit to Chinmay7070/openmrs-core that referenced this pull request Jan 21, 2026
… core or modules changes (openmrs#5603)

* TRUNK-6418: Run liquibase checks and data imports only when version of core or modules changes

(cherry picked from commit 4723e71c3f39a6467ab6f4060dab42a694cd1a68)

* TRUNK-6418: Follow up adjustments

---------

Co-authored-by: IamMujuziMoses <[email protected]>
(cherry picked from commit 55cf1c5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants