| Re: [che-dev] Faster Workspace Loading |
1. AFAIK in SPI branch IDE loads components related to some agent as fast as it becomes available.With this approach implementation of background start of installers is not needed, since IDE can use available servers regardless status of WS.2. Bootstrapper installation sequence is not fixed and depends on installers of a WS.So, it is not absolutely correct to say that after wsagent other installers can be started in the background.It really depends on configured installers, but in common it is the suggested order.3. We can try to implement parallel start of installers.But there are some consequences, such as it is possible that installer would not use things that would make parallel start possible.But, our installers would implement it properly, so it would be an interesting approach in any case.4. We don't have the concept of lazy loading of an installer for now.5. To make wsagent lightweight I suppose we would need to move any additional functionality to LS-like server.--On Tue, Jul 11, 2017 at 3:47 PM, Stevan LeMeur <slemeur@xxxxxxxxxx> wrote:Hi all,I'd like open a discussion on how we can improve the loading sequence of the workspace and connect that to the work on the SPI.Current Workspace Loading SequenceThe following sequence of events will happen while loading the workspace:1. Docker Build or Image Pull2. Create and start container(s)3. Launching "bootstrapper" who is installing/starting the Agents
4. Bootstrapper install and start exec-agents5. Bootstrapper install and start terminal agent6. Bootstrapper start tomcat for ws-agent7. Bootstrapper start other configured agentsToday, all those steps are executed sequentially, one after one, agent after agent until the workspace is available to the use. This makes the duration between when the user request the startup of the workspace and when he is able to use it - quite long.We can make the loading experience better from UI point of view. That's the goal of the following epic: https://github.com/eclipse/che/issues/5231 But in term of UX, the epic will not solve the biggest pain point which is the time needed before the user can start to interact with his workspace.Fasten the Workspace Loading SequenceI'd like to discuss what we could do in order to allow the user being able to get his workspace as fast as possible - so he can start opening his files, browsing projects - even if the workspace is not fully loaded and language toolings is not ready yet.Potentials optimizations:
- 1 - Lighter/Splited WSAgent: Would it be possible to get a simplified version of the ws-agent, which would be very light and fast to start and which would only allow to interact with the files? It would not have all the pieces that the ws-agent is having - but it would allow to load files in the IDE very fast - as soon as the workspace containers are booted.
- 2 - Agents starting: Today, we wait all the agents to be ready before we give the user the ability to interact with the IDE.
- Could we differentiate the agents that are needed for the IDE to be ready for the user from the ones which can be started/initialized in background?
- Could we parallelize the installation and startup of agents? It might not be possible for all agents, but maybe for some of them. With the study from Florent on sidecar containers, it would even be smarter as we could allow agents to be lazy-loaded.
Thanks,What do you think about those potential optimizations?Do you see any other optimization opportunities for the workspace loading sequence so it would reduce the time before the user could be able to interact with his projects/files?Stévan.