Provide rapid workspace starts in a read-only manner as more complete experience loads in background or on a refresh

[sympatheticmoose]

Investigate whether we could adopt a similar approach to github1s to provide a faster initial loading of a workspace with limited capability. Ideally this should work with GitHub, GitLab and Bitbucket

[sparkoo]

AFAIK the biggest "time waste" in workspace startup now is waiting for Ingresses/Routes to initialize. I don't know how exactly it works in the cluster, but from my experience, it can take up to a minute from creating an Ingress object, to the endpoint actually available externally. See this demo I did when we were implementing new gateway single-host https://youtu.be/Fhzt8DiBajU. Top left screen is pure single-host without any new Routes.

Nowdays we're aiming into mixed endpoints, where some workspace endpoints will be single-host (subpaths of main route -> no new Routes) and some multi-host (subdomains -> new Route). Issue is, if you have only one new Route, we're waiting for it in the startup.

I see 2 ways how to improve the situation:

• have essential routes single-host and wait only for those
  • I believe Theia already can do that, so we should be able to get to the editor similar to the video.
• have routes prepared for the user
  • first start would be slow, but then we could leave the routes there (for some time) for reuse

[tsmaeder]

The approach used by github1s (as I understand it) is that it builds a in-browser only version of vscode that uses github repos as a read-only file system.
We could build that (based on theia), but it wouldn't have anything to do with a Che workspace. The problem with Che workspace startup is not starting the IDE (the electron version of Theia starts up in 5s), but standing up the pod that serves that IDE and getting access to it.

[Hadsch]

@sparkoo: Thanks for sharing this info.

I think, these performance considerations should be mentioned here https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-workspace-exposure-strategies/#default-host-workspace-exposure-strategy_che
or here https://www.eclipse.org/che/docs/che-7/end-user-guide/troubleshooting-slow-workspaces/!

[che-bot]

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.