Closed ibuziuk closed 5 years ago
The Initial results of using none
strategy is that workspace startup is pretty much the same as for regular workspaces with PVC attached:
Funny enough that mvn
/ npm
builds are faster in comparison with the same commands executing in the mounted folders e.g. projects
for regular workspaces. Will provide more detailed results soon
Google Drive is a free way to keep your files backed up and easy to reach from any phone, tablet, or computer. Start with 15GB of Google storage – free.
Google Drive is a free way to keep your files backed up and easy to reach from any phone, tablet, or computer. Start with 15GB of Google storage – free.
Tests results for running git clone
/ mvn install
against emptyDir
volume and container FS performance https://github.com/redhat-developer/rh-che/issues/883#issuecomment-420948441
In general, using emptyDir
does not provide any performance benefits
Regarding the test of the current workspace startup using angular2-quickstart
factory [1] against che.openshift.io with fresh PVC (claim-che-workspace
was created during the workspace startup so it was clean from the very beginning). Currently it takes ~70 seconds to start the workspace:
2018/09/13 18:34:27 Bootstrapper configuration 2018/09/13 18:34:27 Push endpoint: wss://che.openshift.io/api/websocket 2018/09/13 18:34:27 Push logs endpoint: wss://che.openshift.io/api/websocket 2018/09/13 18:34:27 Auth enabled: true 2018/09/13 18:34:27 Runtime ID: 2018/09/13 18:34:27 Workspace: workspacepn188p3mtnfsn8j2 2018/09/13 18:34:27 Environment: node 2018/09/13 18:34:27 OwnerId: 9956255a-776f-4c8a-950e-878dc54f871a 2018/09/13 18:34:27 Machine name: ws-machine 2018/09/13 18:34:27 Installer timeout: 180seconds 2018/09/13 18:34:27 Check servers period: 3seconds 2018/09/13 18:34:27 Push logs endpoint reconnect period: 10seconds 2018/09/13 18:34:27 Planning to install 2018/09/13 18:34:27 - com.redhat.oc-login:1.0.0 - Login with oc to user project on OSO 2018/09/13 18:34:27 - org.eclipse.che.exec:1.0.1 - Agent for command execution 2018/09/13 18:34:27 - org.eclipse.che.ws-agent:1.0.3 - Workspace API support 2018/09/13 18:34:27 - org.eclipse.che.terminal:1.0.1 - Embedded web terminal 2018/09/13 18:34:27 Starting installations 2018/09/13 18:34:27 Installing 'com.redhat.oc-login' 2018/09/13 18:34:27 Installation of 'com.redhat.oc-login' successfully finished 2018/09/13 18:34:27 Installing 'org.eclipse.che.exec' 2018/09/13 18:34:30 Installation of 'org.eclipse.che.exec' successfully finished 2018/09/13 18:34:30 Installing 'org.eclipse.che.ws-agent' 2018/09/13 18:34:33 Installation of 'org.eclipse.che.ws-agent' successfully finished 2018/09/13 18:34:33 Installing 'org.eclipse.che.terminal' 2018/09/13 18:34:36 Installation of 'org.eclipse.che.terminal' successfully finished 2018/09/13 18:34:36 All installations successfully finished
Video of workspace startup: https://drive.google.com/file/d/1bYHaPyYTJ4BaAwbue2mIUmEwow6DwEop/view?usp=sharing
This test was done against the newly created PVC and image already existed in the registry, so the workspace container started really fast in just 5 second. I believe workspace startup time would be pretty similar for ephemeral workspaces (of course if pulling image would also be that fast). However, other parts that required ~ 1 minutes would still be there, so it should be expected that the using the same factory with ephemeral workspace would result in pretty much the same time for startup - ~ 60 - 70 seconds. Here is the demo of starting ephemeral workspace which took ~ 90 seconds (image pulling took some time):
https://drive.google.com/file/d/1t06uC7EPNHy6vHKucuxAzLp3V230giqx/view?usp=sharing
@l0rd @gorkem the initial research [1] [2] shows that ephemeral workspaces would not sufficiently improve workspace startup time but would definitely allow to avoid problems with slow PVC mount. In the general case ephemeral workspace startup would still take more than a minute. Current plan is to provide per-workspace implementation of ephemeral workspaces via mountSources
property which would be enabled by default.
[1] https://github.com/redhat-developer/rh-che/issues/883#issuecomment-420948441 [2] https://github.com/redhat-developer/rh-che/issues/879#issuecomment-421124049
Great job. Thank you @ibuziuk
Thanks @ibuziuk If it is not too much trouble can you also compare a Che 7(Theia based) workspace ?
@gorkem yeah sure, I would add info about che 7 performance once we update prod to 6.11.0 [1] & add dedicated factory for it [2]
[1] https://github.com/redhat-developer/rh-che/issues/881 [2] https://github.com/redhat-developer/rh-che/issues/868
Great analysis, @ibuziuk!
Have recorded a demo video [1] of creating ephemeral workspace from factory on minishift. Workspace start up took ~ 45 seconds. Basically, in comparison with oso [2] initial initialization steps (loading che + loading factory + initializing workspace) took just 5
seconds (20
on oso) and final UI initialization / loading worksapce also took 5
seconds (25
on oso). We need to figure what is the main reason of such delays which is probably related to networking communications.
[1] https://youtu.be/bGA5scbuQeg [2] https://github.com/redhat-developer/rh-che/issues/879#issuecomment-421124049
YouTube
Are you comparing local minishift vs OSO hosted in US east coast? I think those are expected to give different results.
@gorkem the last comment is related to the fact that on minishift UI initialization (loading che + loading factory + initializing workspace) & loading workspace happens much faster in comparison with oso where che-server and workspaces are located on different clusters
Closing info about che 7 workspace startup has been provided as part of the https://github.com/redhat-developer/rh-che/issues/1014#issuecomment-437043526
Need to compare performance of:
emptyDir
https://kubernetes.io/docs/concepts/storage/volumes/#emptydirIn order to get data for
emptyDir
first need to implement the relevant strategy for it - https://github.com/redhat-developer/rh-che/issues/883