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.