Troubleshooting slow workspaces
Sometimes, workspaces can take a long time to start. Tuning can reduce this start time. Depending on the options, administrators or users can do the tuning.
This section includes several tuning options for starting workspaces faster or improving workspace runtime performance.
- Caching images with Image Puller
When starting a workspace, Kubernetes pulls the images from the registry. A workspace can include many containers meaning that Kubernetes pulls Pod’s images (one per container). Depending on the size of the image and the bandwidth, it can take a long time.
Image Puller is a tool that can cache images on each of Kubernetes nodes. As such, pre-pulling images can improve start times. See Caching images for faster workspace start.
- Choosing better storage type
Role: Administrator and user
Every workspace has a shared volume attached. This volume stores the project files, so that when restarting a workspace, changes are still available. Depending on the storage, attach time can take up to a few minutes, and I/O can be slow.
To avoid this problem, use ephemeral or asynchronous storage. See Configuring storage types.
- Installing offline
Components of Che are OCI images. Set up Eclipse Che in offline mode (air-gap scenario) to reduce any extra download at runtime because everything needs to be available from the beginning. See Installing Che in a restricted environment.
- Optimizing workspace plug-ins
When selecting various plug-ins, each plug-in can bring its own sidecar container, which is an OCI image. Kubernetes pulls the images of these sidecar containers.
Reduce the number of plug-ins, or disable them to see if start time is faster. See also Caching images for faster workspace start.
- Reducing the number of public endpoints
For each endpoint, Kubernetes is creating Kubernetes Ingress or OpenShift Route objects. Depending on the underlying configuration, this creation can be slow.
To avoid this problem, reduce the exposure. For example, to automatically detect a new port listening inside containers and redirect traffic for the processes using a local IP address (
127.0.0.1), the Che-Theia IDE plug-in has three optional routes.
By reducing the number of endpoints and checking endpoints of all plug-ins, workspace start can be faster.
- CDN configuration
The IDE editor uses a CDN (Content Delivery Network) to serve content. Check that the content uses a CDN to the client (or a local route for offline setup).
To check that, open Developer Tools in the browser and check for
vendorsin the Network tab.
editor.main.*should come from CDN URLs.
- Providing enough CPU resources
Plug-ins consume CPU resources. For example, when a plug-in provides IntelliSense features, adding more CPU resources may lead to better performance.
Ensure the CPU settings in the devfile definition,
devfile.yaml, are correct:
apiVersion: 1.0.0 components: - type: chePlugin id: id/of/plug-in cpuLimit: 1360Mi (1) cpuRequest: 100m (2)
1 Specifies the CPU limit for the plug-in. 2 Specifies the CPU request for the plug-in.
- Providing enough memory
Plug-ins consume CPU and memory resources. For example, when a plug-in provides IntelliSense features, collecting data can consume all the memory allocated to the container.
Providing more memory to the plug-in can increase performance. Ensure about the correctness of memory settings:
in the plug-in definition -
in the devfile definition -
apiVersion: v2 spec: containers: - image: "quay.io/my-image" name: "vscode-plugin" memoryLimit: "512Mi" (1) extensions: - https://link.to/vsix
1 Specifies the memory limit for the plug-in.
In the devfile definition (
apiVersion: 1.0.0 components: - type: chePlugin id: id/of/plug-in memoryLimit: 1048M (1) memoryRequest: 256M
1 Specifies the memory limit for this plug-in.
- Choosing better storage type
Use ephemeral or asynchronous storage for faster I/O. See Configuring storage types.