Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Che workspace takes too much time to load #16

Open
deanone opened this issue Sep 20, 2022 · 14 comments
Open

Che workspace takes too much time to load #16

deanone opened this issue Sep 20, 2022 · 14 comments
Assignees
Labels
performance Something takes too much time to work

Comments

@deanone
Copy link

deanone commented Sep 20, 2022

Dear @goncalorolo,

I have made several tests on the platform and I noticed that even for existing services (i.e., for services that the Che workspace has already been created) the workspace takes too much time to load. It is about 2 to 3 minutes.

So, I think that this is something that we need to check since it affects the whole user experience.

@deanone deanone added the performance Something takes too much time to work label Sep 20, 2022
@goncalorolo
Copy link
Contributor

Even though it is not as severe as for new workspaces, starting a workspace usually takes some time, which is something we have had to put up with since the first experiments in the Che dashboard.

It is true that it undermines the user experience but there seems to be no simple solution for this.

@deanone
Copy link
Author

deanone commented Sep 21, 2022

I'll investigate this more thoroughly. You know, yesterday I was presenting the platform to the ORW and during the live demo the Che workspace for a test project that I had already created before the meeting took like 3-4 minutes to load. This is way too long. Any developer that would experience such a delay on a development tool, most probably he will quickly drop it and move to the next.

@goncalorolo
Copy link
Contributor

I'll investigate this more thoroughly. You know, yesterday I was presenting the platform to the ORW and during the live demo the Che workspace for a test project that I had already created before the meeting took like 3-4 minutes to load. This is way too long. Any developer that would experience such a delay on a development tool, most probably he will quickly drop it and move to the next.

Yes, that is the usual behaviour. The only way to avoid showing that in the presentation would have been to open the workspace beforehand and leave it open (you can leave Che-Theia in the IDE frontend by clicking the logo of the project in the header because that changes the page but leaves the workspace running, whereas the "Close" option in the sidebar stops it).

@deanone
Copy link
Author

deanone commented Sep 21, 2022

I'll investigate this more thoroughly. You know, yesterday I was presenting the platform to the ORW and during the live demo the Che workspace for a test project that I had already created before the meeting took like 3-4 minutes to load. This is way too long. Any developer that would experience such a delay on a development tool, most probably he will quickly drop it and move to the next.

Yes, that is the usual behaviour. The only way to avoid showing that in the presentation would have been to open the workspace beforehand and leave it open (you can leave Che-Theia in the IDE frontend by clicking the logo of the project in the header because that changes the page but leaves the workspace running, whereas the "Close" option in the sidebar stops it).

Yes, but the think is that I wanted to actually show the workspace launching. That's why I created a service beforehand because I thought that the Che workspace will launch (more or less) quickly, if it was not the first time launching the workspace.

I believe that a workaround exists. We just need to find it.

@goncalorolo
Copy link
Contributor

Yes, but the think is that I wanted to actually show the workspace launching. That's why I created a service beforehand because I thought that the Che workspace will launch (more or less) quickly, if it was not the first time launching the workspace.

Oh, I see. Well, yes, the first time you run the workspace is when it takes the longest. The following attempts are a bit better but still noticeably slow.

@deanone
Copy link
Author

deanone commented Nov 24, 2022

Dear @goncalorolo ,

We really need to have a closer look at this issue. Today I tried to load the workspaces of existing services that I have created through the platform, and each load took to much time. For example, in one case, I had to wait for more than 10 minutes!!

Any ideas on what may cause this issue?

@goncalorolo
Copy link
Contributor

In this particular case, I think workspaces were taking too much time to start due to a Che downtime (which also led to #32). I have just tried starting an existing workspace and creating a new one and starting it afterwards and both processes didn't take more than 2 minutes each.

@deanone
Copy link
Author

deanone commented Nov 25, 2022

@goncalorolo indeed I just tried to load an existing workspace and I took around 2.5 minutes.

However, I want to ask, is this normal in general? I mean, has it been reported somewhere that Che workspaces are very slow to load?

@deanone
Copy link
Author

deanone commented Nov 30, 2022

@goncalorolo any thoughts on that?

@goncalorolo
Copy link
Contributor

There is this page in the documentation. @philipreimer, do you think any of these practices whose role is "Administrator" can still be followed in order to improve the loading times?

@eclipse-opensmartclide eclipse-opensmartclide locked and limited conversation to collaborators Dec 5, 2022
@reimer-atb
Copy link
Contributor

reimer-atb commented Dec 5, 2022

  • Caching images with Image Puller: we can try to add this Image Puller. What would be the list of images to pre-pull?:

    Semicolon-separated list of images to pull, in the format =;=. See Defining the list of images to pull.

  • Choosing better storage type: not much information here. What would be a "better storage type"???
  • Installing offline: not applicable, I think, because we don't use Openshift
  • Optimizing workspace plug-ins: not sure if @goncalorolo can do anything about that?
  • Reducing the number of public endpoints: not sure if @goncalorolo can do anything about that?
  • CDN configuration: this is already the case. vendor.*.js and editor.main.* are served from CDN.

/cc @schlotze

@goncalorolo
Copy link
Contributor

goncalorolo commented Dec 5, 2022

  • Optimizing workspace plug-ins: not sure if @goncalorolo can do anything about that?

The devfile templates we currently provide only use the minimum subset of plugins needed. Therefore, we cannot optimise this any further.

EDIT: For everyone's information, I have tried reducing the number of plug-ins and it only improved the loading performance the first time the workspace is started. All subsequent launches take the same amount of time, which increases with the number of plug-ins.

  • Reducing the number of public endpoints: not sure if @goncalorolo can do anything about that?

Similarly to the previous bullet point, there are no unused public endpoints being exposed.

@reimer-atb
Copy link
Contributor

@goncalorolo @deanone Regarding the image puller: the documentation states:

For faster workspace startup times, consider pulling workspace related images such as universal-developer-image, che-code`, and che-gateway.

When looking at https://plugin-registry-smartclide-che.che.smartclide.eu/v3/external_images.txt none of the recommended images appear there.

Would it make sense to try to cache any of the other images from that list?

@deanone
Copy link
Author

deanone commented Dec 6, 2022

@goncalorolo @deanone Regarding the image puller: the documentation states:

For faster workspace startup times, consider pulling workspace related images such as universal-developer-image, che-code`, and che-gateway.

When looking at https://plugin-registry-smartclide-che.che.smartclide.eu/v3/external_images.txt none of the recommended images appear there.

Would it make sense to try to cache any of the other images from that list?

@philipreimer @goncalorolo I think it is worth trying to pull the recommended images universal-developer-image, che-code`, and che-gateway

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
performance Something takes too much time to work
Projects
None yet
Development

No branches or pull requests

3 participants