[jboss-jira] [JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
[
https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin....
]
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...
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)