You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to suggest that the pattern of implementation for the BWCE startup scripts be changed as there is large amount of time spent during runtime startup that could have been executed during the build phase of the Application image that has been built on top of the BWCE image.
The normal pattern of usage is that the start.sh & setup.sh are executed during the deployed service image startup. This means that during the deployed service startup the is copying files and unzipping the runtime on the image. This incurs a large amount of CPU usage during startup and is not in line in having an immutable image that is loaded as changes are being made during runtime.
I would suggest that the setup.sh is being used for two purposes - build and execute of the tibco service. If we can separate the run activities possibly into a run.sh from the build activities in the setup.sh then the deployed service image build could be separated into multi stage build process one step that builds the image publishes it into the run image.
Changing this implementation pattern would be a large benefit to the runtime startup performance of the deployed bw component
The text was updated successfully, but these errors were encountered:
** This is a feature request **
I would like to suggest that the pattern of implementation for the BWCE startup scripts be changed as there is large amount of time spent during runtime startup that could have been executed during the build phase of the Application image that has been built on top of the BWCE image.
The normal pattern of usage is that the start.sh & setup.sh are executed during the deployed service image startup. This means that during the deployed service startup the is copying files and unzipping the runtime on the image. This incurs a large amount of CPU usage during startup and is not in line in having an immutable image that is loaded as changes are being made during runtime.
I would suggest that the setup.sh is being used for two purposes - build and execute of the tibco service. If we can separate the run activities possibly into a run.sh from the build activities in the setup.sh then the deployed service image build could be separated into multi stage build process one step that builds the image publishes it into the run image.
Changing this implementation pattern would be a large benefit to the runtime startup performance of the deployed bw component
The text was updated successfully, but these errors were encountered: