che
che copied to clipboard
eclipse-che
Faster workspace startup experience
Goal
One of the most important value prop of Eclipse Che is the disposable and on-demand aspect of the developer workspaces, which shift the development paradigm. It is also key in the adoption of tools, developer love when it is fast.
Problem With the introduction of Che 7 based workspaces, the loading time of the workspaces has been growing significantly. A workspace is going to pull more containers and the load of the binaries of the extensions is also going to impact the loading performance.
Prioritized components load / minimal pull of images and components / lazy loading
When a user is starting a workspace, the workspace should start a very small subset of containers. For example only the Editor part. Then, VS Code Extensions, are downloaded in the background as well as all the specific runtimes. When the tooling is ready, the workspace is updated and a rollout upgrade of the Editor (Che-Theia) is used. Che-Theia has now the whole tooling ready and user is notified. It can be an incremental upgrade of the editor (like every 5s for every plug-in being ready, for every plug-in ready, etc).
Optimized broker / init containers
The plugin broker shouldn’t download the VS Code extension vsix at each workspace start. We could include the extension in the runtime image built offline. Then restarting a workspace or starting a workspace with the same VS Code extensions than a previous user will reuse container images.
Cache of images and components
When an image, a plugin’s binary, a component has been pulled that should be cached and available to all the users.
List of Subtasks
- [x] https://github.com/eclipse/che/issues/14494
- [x] https://github.com/eclipse/che/issues/15385
- [x] https://github.com/eclipse/che/issues/12914
- [x] https://github.com/eclipse/che/issues/18672
- [x] https://github.com/eclipse/che/issues/19461
- [x] https://github.com/eclipse/che/issues/15384
- [x] https://github.com/eclipse/che/issues/19718
- [x] https://github.com/eclipse/che/issues/20592
- [ ] https://github.com/devfile/devworkspace-operator/issues/209
- [ ] Use a PV to cache users VS Code binary
Added a subtask that has an existing issue.
@slemeur I'm not clear on what the last topic entails:
- Images are available to all users by default (since they're stored in the internal image repo on the cluster; however this is on a node-by-node basis.
- Would offline support for the plugin registry solve the plugin's binary component? Currently it's possible to build a plugin registry that has all extensions to be downloaded served locally. If so, there's a few tasks left on this: https://github.com/eclipse/che/issues/14573#issuecomment-540027033 (could be a subtask attached to this epic)
- The offline registry above also impacts the first point (lazy start of components), since the offline registry enables Che to pull in plugin artifacts very quickly in many cases.
Regarding the first point, I think more investigation would be necessary; in my experience, the starting of the containers isn't the biggest problem, it's pulling images and waiting for Theia to be responsive. Integrating a rollout into the start process may wipe out much of the time saved if Theia has to restart.
I don't expirence any issues on a real cluster. with a dedicated docker registry proxy and a vscode extensions proxy local to the cluster. i also use apt and yum proxys and node npm proxys its part of my general flow as i always want to have a copy of all needed packages.
On the online approach, https://github.com/eclipse/che-plugin-broker/pull/63 may provide some helps. In addition, the download phase can be done in parallel.
And it may be effective pre-loading docker images to nodes by DaemonSet.
Should this include the work started by @davidfestal on CRDs and remove the SPI ? we would gain 10 secs sometimes.
ImagePull policies set to IfNotPresent make workspace startup faster https://github.com/eclipse/che/issues/14698#issuecomment-620586805.
Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.
Mark the issue as fresh with /remove-lifecycle stale in a new comment.
If this issue is safe to close now please do so.
Moderators: Add lifecycle/frozen label to avoid stale mode.
