My app builds slower in a dev container than in my laptop, what can I do?
Dev containers’ performance is a crucial part of the Okteto developer experience. To enhance the speed of your dev containers, we recommend adhering to several best practices:
- Optimize the files synchronized to your dev container via the
- Configure persistency for your programming language and framework caches
- Configure CPU/Memory resources for your dev containers
- Configure faster storage for your dev containers
When you execute
okteto up, Okteto synchronizes your local file system to your remote dev container. This operation can be optimized in several ways:
- If your dev image comes with your code, the synchronization will be faster because Okteto detects your local files are already available in the remote dev container
- Ignore files you don’t need for development, like documentation images or build artifacts. In particular, always ignore your
.gitfolder. It’s not only a fat folder, but it also introduces bad behaviors in the synchronization protocol
- Build your dependencies on remote. For example, don’t sync
node_modules. You can generate
node_moduleson remote and avoid the synchronization of thousands on files.
Most programming languages and frameworks come with cache folders to optimize the subsequent builds of your application. You can persist these folders using the volumes section of the Okteto Manifest. You can check some of our samples for different programming languages:
Follow this link for a list of the cache folders used by other programming languages and frameworks.
During the Okteto installation, you can configure the default CPU and memory resources allocated for every container deployed to Okteto using quotas. The default values for every container are:
resources: requests: cpu: 100m memory: 0.2Gi limits: cpu: 2 memory: 8Gi
At deployment time, you can configure your own resources for your pods in your Kubernetes manifests or Docker Compose file. You can also configure the resources of your dev containers in the resources section of your Okteto Manifest.
Note that the performance of your dev containers can be significantly influenced by the type of processor it runs on. Different virtual machines (VMs) may have processors with varying capabilities. In you are running Okteto Self-hosted, you can enhance performance by configuring your dev containers to run on a dedicated node pool with a high-speed processor. You can do this for every dev container using tolerations or nodeSelectors in your Okteto Manifest:
tolerations: - key: nvidia.com/gpu operator: Exists nodeSelector: disktype: ssd
You can also configure this behavior for all your dev containers across the board using the field affinities
upPool in your Okteto helm values file. For example, like this:
affinity: required: true upPool: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: okteto-pool-type operator: In values: - dev-containers
In Okteto Self-hosted, there is another configuration setting that can significantly boost the performance of your dev containers is the choice of storage associated with the Persistent Volume created by
okteto up. Dev containers are usually I/O intensive, and opting for SSDs over standard disks can substantially impact build performance. You can configure the storage class your dev container using the field persistentVolume.storageClass in your Okteto Manifest:
persistentVolume: enabled: true storageClass: ssd size: 30Gi
You can also configure this behavior for all your dev containers across the board using the field devStorageClass in your Okteto helm values file:
devStorageClass: enabled: true storageClass: ebs-sc
There are some scenarios where building and running your application locally is faster than using a remote dev container. Or when code sync can introduce friction points like the impossibility to sync the
.git folder to your remote dev container.
For these scenarios, we have developed the
hybrid mode for
okteto up. When using hybrid mode, you can run one of the services of your application locally, but make it accessible to others services running in the cluster and viceversa.
You can find more information about hybrid mode in the following samples: