Uploaded image for project: 'WildFly WIP'
  1. WildFly WIP
  2. WFWIP-276

Boot time of application built via S2I is much longer than in before-Galleon times

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Critical Critical
    • OpenShift
    • None
    • Hide
      oc new-app --name=test-app17 registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-eap-cd-openshift-rhel8:17.0-6~/tmp/test-app --insecure-registry=true --build-env=SCRIPT_DEBUG=true --env=CUSTOM_INSTALL_DIRECTORIES=mypg_module,mypg_driver --env=DRIVERS=MYPG --env=MYPG_DRIVER_NAME=mypg --env=MYPG_DRIVER_MODULE=org.mypg --env=MYPG_XA_DATASOURCE_CLASS=org.postgresql.xa.PGXADataSource
      
      oc new-app --name=test-app18 registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-eap-cd-openshift-rhel8:18.0-7~/tmp/test-app --insecure-registry=true --build-env=SCRIPT_DEBUG=true --env=CUSTOM_INSTALL_DIRECTORIES=mypg_module,mypg_driver --env=DRIVERS=MYPG --env=MYPG_DRIVER_NAME=mypg --env=MYPG_DRIVER_MODULE=org.mypg --env=MYPG_XA_DATASOURCE_CLASS=org.postgresql.xa.PGXADataSource
      
      Show
      oc new -app --name=test-app17 registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-eap-cd-openshift-rhel8:17.0-6~/tmp/test-app --insecure-registry= true --build-env=SCRIPT_DEBUG= true --env=CUSTOM_INSTALL_DIRECTORIES=mypg_module,mypg_driver --env=DRIVERS=MYPG --env=MYPG_DRIVER_NAME=mypg --env=MYPG_DRIVER_MODULE=org.mypg --env=MYPG_XA_DATASOURCE_CLASS=org.postgresql.xa.PGXADataSource oc new -app --name=test-app18 registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-eap-cd-openshift-rhel8:18.0-7~/tmp/test-app --insecure-registry= true --build-env=SCRIPT_DEBUG= true --env=CUSTOM_INSTALL_DIRECTORIES=mypg_module,mypg_driver --env=DRIVERS=MYPG --env=MYPG_DRIVER_NAME=mypg --env=MYPG_DRIVER_MODULE=org.mypg --env=MYPG_XA_DATASOURCE_CLASS=org.postgresql.xa.PGXADataSource

      1. 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.

              jdenise@redhat.com Jean Francois Denise
              jbliznak@redhat.com Jan Blizňák
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: