[jboss-jira] [JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

[Kabir Khan (Jira)]

    [ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818895#comment-13818895 ] 

Kabir Khan commented on WFWIP-276:
----------------------------------


I have investigated very briefly how this could work. The hook is after the call to extensibleConfigurationPersister.load() here https://github.com/wildfly/wildfly-core/blob/11.0.0.Beta3/server/src/main/java/org/jboss/as/server/ServerService.java#L392

My initial idea was to look for a user specified file (in my play I used a system property to specify the file location) containing the CLI commands and to parse those and add those to the bootOps. However, this is too naive. The reason is that the CLI scripts make heavy use of CLI control flow, batching and things like that. 

So it seems to me that if we tell it to use 'additional' operations from a CLI file, we would need to add a hidden operation handler and add an operation to bootOps to invoke this operation. We would need to make sure this gets executed at the end of the MODEL stage. If it can be removed after boot that would be great (there is a call a few lines further down from what I pasted to registerModelControllerServiceInitializationBootStep() which sounds like it is doing something like that).

The handler for this operation could then take specified CLI script(s) and use CLI running in some kind of mode where it calls the local ModelController directly rather than remotely. I don't know if we have what we need to do that already? If we do, I believe this would be able to adjust the configuration parsed from the standalone.xml config file with control flow and everything.



> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
>                 Key: WFWIP-276
>                 URL: https://issues.jboss.org/browse/WFWIP-276
>             Project: WildFly WIP
>          Issue Type: Bug
>          Components: OpenShift
>            Reporter: Jan Blizňák
>            Assignee: Jean Francois Denise
>            Priority: Critical
>         Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1	| 8283|6128|2155
> |#2	| 9446|7548|1898
> |#3	| 8767|6871|	1896
> |#4	| 8568|6272|	2296
> |#5	| 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1             |13769|5716|8053
> |#2             |13362|5952|7410
> |#3             |14261|6093|8168
> |#4             |14322|6135|8187
> |#5             |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself ==  {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. 
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)