Skip to content

docs: add new best practice doc to speed up templates and workspaces #15296

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

Merged
merged 22 commits into from
Nov 1, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
make fmt
  • Loading branch information
EdwardAngert committed Oct 30, 2024
commit 3073ab7528667bada5999e81c5acc6d83e092bb5
63 changes: 47 additions & 16 deletions docs/tutorials/best-practices/speed-up-templates.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,17 +4,22 @@ October 31, 2024

---

If it takes your workspace a long time to start, find out why and make some changes to your Coder templates to help speed things up.
If it takes your workspace a long time to start, find out why and make some
changes to your Coder templates to help speed things up.

## Monitoring

You can monitor [Coder logs](../../admin/monitoring/logs.md) through the system-native tools on your deployment platform, or stream logs to tools like Splunk, Datadog, Grafana Loki, and others.
You can monitor [Coder logs](../../admin/monitoring/logs.md) through the
system-native tools on your deployment platform, or stream logs to tools like
Splunk, Datadog, Grafana Loki, and others.

### Coder Observability Chart

Use the [Observability Helm chart](https://github.com/coder/observability) for a pre-built set of monitoring integrations.
Use the [Observability Helm chart](https://github.com/coder/observability) for a
pre-built set of monitoring integrations.

With the Observability Helm chart, you can monitor [which specific startup metrics are a part of the Helm chart?]
With the Observability Helm chart, you can monitor [which specific startup
metrics are a part of the Helm chart?]

To install it with Helm:

Expand All @@ -25,15 +30,23 @@ helm upgrade --install coder-observability coder-observability/coder-observabili

### Enable Prometheus metrics for Coder

Our observability bundle gives you this for free which is nice and has instructions on how to do it with Coder
Our observability bundle gives you this for free which is nice and has
instructions on how to do it with Coder

[Prometheus.io](https://prometheus.io/docs/introduction/overview/#what-is-prometheus) is included as part of the [observability chart](#coder-observability-chart).It offers a variety of [available metrics](../../admin/integrations/prometheus.md#available-metrics).
[Prometheus.io](https://prometheus.io/docs/introduction/overview/#what-is-prometheus)
is included as part of the [observability chart](#coder-observability-chart).It
offers a variety of
[available metrics](../../admin/integrations/prometheus.md#available-metrics).

You can [install it separately](https://prometheus.io/docs/prometheus/latest/getting_started/) if you prefer.
You can
[install it separately](https://prometheus.io/docs/prometheus/latest/getting_started/)
if you prefer.

### Workspace build timeline

Use the **Build timeline** to monitor the time it takes to start specific workspaces. Identify long scripts, resources, and other things you can potentially optimize within the template.
Use the **Build timeline** to monitor the time it takes to start specific
workspaces. Identify long scripts, resources, and other things you can
potentially optimize within the template.

![Screenshot of a workspace and its build timeline](../../images/best-practice/build-timeline.png)

Expand All @@ -45,29 +58,45 @@ curl -X GET http://coder-server:8080/api/v2/workspacebuilds/{workspacebuild}/tim
-H 'Coder-Session-Token: API_KEY'
```

Visit the [API documentation](../../reference/api/builds.md#get-workspace-build-timings-by-id) for more information.
Visit the
[API documentation](../../reference/api/builds.md#get-workspace-build-timings-by-id)
for more information.

## Provisioners

`coder server` defaults to three provisioner daemons. Each provisioner daemon can handle one single job, such as start, stop, or delete at a time and can be resource intensive. When all provisioners are busy, workspaces enter a "pending" state until a provisioner becomes available.
`coder server` defaults to three provisioner daemons. Each provisioner daemon
can handle one single job, such as start, stop, or delete at a time and can be
resource intensive. When all provisioners are busy, workspaces enter a "pending"
state until a provisioner becomes available.

### Increase provisioner daemons

Provisioners are queue-based to reduce unpredictable load to the Coder server. However, they can be scaled up to allow more concurrent provisioners. You risk overloading the central Coder server if you use too many local provisioners, so we recommend a maximum of five provisioners. For more than five provisioners, we recommend that you move to [external provisioners](../../admin/provisioners.md).
Provisioners are queue-based to reduce unpredictable load to the Coder server.
However, they can be scaled up to allow more concurrent provisioners. You risk
overloading the central Coder server if you use too many local provisioners, so
we recommend a maximum of five provisioners. For more than five provisioners, we
recommend that you move to [external provisioners](../../admin/provisioners.md).

If you can’t move to external provisioners, use the `provisioner-daemons` flag to increase the number of provisioner daemons to five:
If you can’t move to external provisioners, use the `provisioner-daemons` flag
to increase the number of provisioner daemons to five:

```shell
coder server --provisioner-daemons=5
```

Visit the [CLI documentation](../../reference/cli/server.md#--provisioner-daemons) for more information about increasing provisioner daemons and other options.
Visit the
[CLI documentation](../../reference/cli/server.md#--provisioner-daemons) for
more information about increasing provisioner daemons and other options.

### Adjust provisioner CPU/memory

We recommend that you deploy Coder to its own respective Kubernetes cluster, separate from production applications. Keep in mind that Coder runs development workloads, so the cluster should be deployed as such, without production-level configurations.
We recommend that you deploy Coder to its own respective Kubernetes cluster,
separate from production applications. Keep in mind that Coder runs development
workloads, so the cluster should be deployed as such, without production-level
configurations.

Adjust the CPU and memory values as shown in [Helm provisioner values.yaml](https://github.com/coder/coder/blob/main/helm/provisioner/values.yaml#L134-L141):
Adjust the CPU and memory values as shown in
[Helm provisioner values.yaml](https://github.com/coder/coder/blob/main/helm/provisioner/values.yaml#L134-L141):

```yaml
Expand All @@ -82,7 +111,9 @@ Adjust the CPU and memory values as shown in [Helm provisioner values.yaml](http
```

Visit the [validated architecture documentation](../../admin/infrastructure/validated-architectures/index.md#workspace-nodes) for more information.
Visit the
[validated architecture documentation](../../admin/infrastructure/validated-architectures/index.md#workspace-nodes)
for more information.

## Set up Terraform Provider Caching

Expand Down