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.

Improving workspace start time

Caching images with Image Puller

Role: Administrator

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.

Installing offline

Role: Administrator

Components of Che are OCI images. Set up Eclipse Che in offline mode to reduce any extra download at runtime because everything needs to be available from the beginning. See Installing Che in a restricted environment on OpenShift.

Optimizing workspace plugins

Role: User

When selecting various plugins, each plugin can bring its own sidecar container, which is an OCI image. Kubernetes pulls the images of these sidecar containers.

Reduce the number of plugins, or disable them to see if start time is faster. See also Caching images for faster workspace start.

Reducing the number of public endpoints

Role: Administrator

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 (, the Che-Theia IDE plugin has three optional routes.

By reducing the number of endpoints and checking endpoints of all plugins, 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 vendors in the Network tab. vendors.<random_id>.js or editor.main.* should come from CDN URLs.

Improving workspace runtime performance

Providing enough CPU resources

Plugins consume CPU resources. For example, when a plugin provides IntelliSense features, adding more CPU resources can improve performance.

Ensure the CPU settings in the devfile definition, devfile.yaml, are correct:

apiVersion: 1.0.0

    type: chePlugin
    id: __<plugin_id>__
    cpuLimit: 1360Mi (1)
    cpuRequest: 100m (2)
1 Specifies the CPU limit for the plugin.
2 Specifies the CPU request for the plugin.
Providing enough memory

Plug-ins consume CPU and memory resources. For example, when a plugin provides IntelliSense features, collecting data can consume all the memory allocated to the container.

Providing more memory to the plugin can increase performance. Ensure about the correctness of memory settings:

  • in the plugin definition - meta.yaml file

  • in the devfile definition - devfile.yaml file

    apiVersion: v2
        - image: ""
          name: "vscode-plugin"
          memoryLimit: "512Mi" (1)
    1 Specifies the memory limit for the plugin.

    In the devfile definition (devfile.yaml):

    apiVersion: 1.0.0
        type: chePlugin
        id: __<plugin_id>__
        memoryLimit: 1048M  (1)
        memoryRequest: 256M
    1 Specifies the memory limit for this plugin.