Extended cache warming

Technical Questions
1

We have some screens and transitions that take notably more time to render/run the first time, mostly because they do several entity-finds which are then cached or they use a number of classes that need to be loaded and then stay in memory. Updating a running moqui instance is generally very smooth for the user and does not interrupt any session, currently the only disruption is when a user is the first one to trigger the rendering of one of these screens or execution of a service that take noticeably longer to run that one time. It is kind of annoying when the user is mid-session and suddenly an action the user has been making repeatedly suddenly takes 5 or 10 times as long.

The cache warming actions for instances set to production purpose are targeted at loading the definitions for entities, services and screens, and do not attempt to improve the actual usage of these artifacts. And it would probably not be very useful to attempt caching all possibly reachable artifact usage as the need-to-be-fast artifact list is a very site-specific issue, and we generally would know exactly which screen rendering or which service run would cause these slow hits.

Would it make sense to have a list of screens that should be rendered before starting the jetty server, so the first request that could be served by moqui would be after this rendering, and so be prepared to make the transition to a new moqui instance even smoother? I am thinking about something like adding values to the moqui.screen.ScreenScheduled entity with some indicator and handle them in the ServiceFacade.wamCache() method.

2

The main things the cache warming for screens and services does not do, and that takes considerable time (up to hundreds of milliseconds) is on the fly compiling the inline groovy scripts, including XML Actions that are converted to Groovy scripts.

One way to do with would be to add some init code (in conf file after-startup actions or in a ToolFactory or something) that renders the screens with code similar to screen render test code.

I don’t know what the startup time would look like, but another option would be to change the ScreenDefinition and ServiceDefinition classes to compile the groovy scripts for all XML Actions when the def is loaded instead of waiting until it is first rendered, perhaps with a config flag or something.

What sorts of delays are you looking at? Usually this isn’t too much of a concern because while it is a slower response it is not more than 1/2 to 1 second.