Startup Time Impact from Drools Compilation (v2.52.1) #80
Description
Hey ICE team, I recently deployed the v2.52.1 upgrade to a fleet of ECS tasks running ICE and noticed that the startup time for the application seems to have taken a hit as part of the upgrade. I believe this is related to the Drool 7s → Drools 10 upgrade. When moving to Drools 10's mandatory "Executable Model," the Drools rules are all pre-compiled on application startup whereas in earlier versions these rules were read and compiled on-the-fly after startup (while serving requests).
I was able to (with a lot of help from Claude, since I'm no expert in the build process) split the repo into two packages: one package builds a .kjar that holds all the compiled Drools rules while the other package takes this knowledge jar as a dependency and builds the .war that Tomcat starts. I verified this custom build served requests as expected and then deployed it to the ECS fleet and recorded significantly reduced startup times (and slightly lower memory utilization since the app doesn't have to hold all the compiled rules in memory).
Do you think it would it be possible to ship a version of ICE that uses Drools rules compiled during the build?
In the meantime, I am using v2.52.1 in my ECS fleet. The impact of the startup time change for me simply manifests as a much slower time when scaling the fleet horizontally when traffic increases.
Supporting Evidence:
The figure below is a histogram that plots the startup time ICE (via the log line "Server startup ..."). The datapoints are hued by the fleet type:
<v2.52.1: The startup times reported by the last ~4 weeks of ECS tasks that have launched running some version of ICE before 2.52.1 (I think v2.51.1 in most cases).
=v2.52.1: The startup times reported by ECS tasks launching with the latest release of ICE, v2.52.1.
=v2.52.1+kjar: The startup times reported by ECS tasks launching with the custom build of v2.52.1 that I built on top of main-v2's cf1e6281 commit.
PS: Other than the increase in startup time and despite all the core service updates involved, I found the upgrade to v2.52.1 was delightfully straightforward. Thanks for all your hard work!