docs: add a section about latency and how it's measured #16734
Conversation
fb514c1 to
d19839f
Compare
|
this one's a blend of trolling through discussions, issues, and code along with a mix of guessing and Claude, but it should get us started |
docs/admin/networking/index.md
Outdated
|
|
||
| - Dashboard-to-server latency: | ||
|
|
||
| The Coder UI measures round-trip time to the Coder server using the browser's Performance API. |
There was a problem hiding this comment.
Coder server or workspace proxy
There was a problem hiding this comment.
updated to
The Coder UI measures round-trip time to the Coder server
+ or workspace proxy
using the browser's Performance API.|
|
||
| The Coder UI measures round-trip time to the Coder server using the browser's Performance API. | ||
|
|
||
| This appears in the user interface next to your username, showing how responsive the dashboard is. |
There was a problem hiding this comment.
It's a bit more complex if there are multiple workspace proxies. The dashboard is always served from the primary Coder server deployment, which will be one specific entry, although I don't think we do anything special to indicate which one, unfortunately.
The other workspace proxies serve applications from the workspace, like web IDEs, the web terminal, etc. A low ping there will help those applications be more responsive, but it only measures part of the round-trip. The proxy to workspace leg is not measured.
There was a problem hiding this comment.
I had trouble figuring out how to add that to this doc in a way that doesn't take it too far off course, so I added it to workspace-proxies.md in 9e7dc7b
I also force-pushed to this branch because I repointed it to main so that the latency info isn't tied to a rework of the networking docs in general. hopefully I did that as cleanly as possible 🤞
docs/admin/networking/index.md
Outdated
| - Workspace (direct P2P connection when possible) | ||
| - DERP relay servers (when P2P isn't possible) | ||
|
|
||
| This latency is visible in workspace cards and resource pages. It shows the round-trip time in milliseconds. |
There was a problem hiding this comment.
Ok, I've looked into this, and admittedly I'm a bit embarassed by what we built.
The latency on the Agent resource card is between the Agent and the shown relay. It never shows P2P (which isn't possible to achieve via the web browser anyway).
The estimated total latency if you were to access a workspace via the browser would be if you added the numbers by your username to the numbers you see in the Agent card, then that would give you a rough picture of the total latency thru various relays.
docs/admin/networking/index.md
Outdated
|
|
||
| - **Deploy workspace proxies**: Place [proxies](./workspace-proxies.md) in regions closer to users. | ||
| - **Use P2P connections**: Ensure network configurations permit direct connections. | ||
| - **Regional deployments**: Place Coder servers in regions where most users work. |
There was a problem hiding this comment.
Careful with the pluralization here. There should only be one Coder server deployment, located somewhere close to the most users. It can have multiple replicas for scale.
There was a problem hiding this comment.
- **Deploy workspace proxies**: Place [proxies](./workspace-proxies.md) in regions closer to users, connecting back to your single Coder server deployment.
- **Use P2P connections**: Ensure network configurations permit direct connections.
- **Strategic placement**: Deploy your Coder server in a region where most users work.
- **Network configuration**: Optimize routing between users and workspaces.ebcf83c to
c09cedf
Compare
docs/admin/networking/index.md
Outdated
| The latency shown on the workspace dashboard measures the round-trip time between the workspace agent and its DERP relay server. | ||
|
|
||
| This metric is displayed in milliseconds on the workspace dashboard and specifically shows the agent-to-relay latency, not direct P2P connections. | ||
|
|
||
| Total end-to-end latency experienced by a user is a combination of dashboard-to-server latency plus this agent-to-relay latency. | ||
|
|
||
| - Database latency: | ||
|
|
||
| For administrators, Coder monitors and reports database query performance in the health dashboard. |
There was a problem hiding this comment.
Ok, I've looked into this, and admittedly I'm a bit embarassed by what we built.
The latency on the Agent resource card is between the Agent and the shown relay. It never shows P2P (which isn't possible to achieve via the web browser anyway).
The estimated total latency if you were to access a workspace via the browser would be if you added the numbers by your username to the numbers you see in the Agent card, then that would give you a rough picture of the total latency thru various relays.
@spikecurtis copying your comments over so they don't get lost
I removed the lines you had commented on, and replaced them with this. Do you think it helps to point out not direct P2P connections or should we cut that?
There was a problem hiding this comment.
I think "not direct P2P connections" is useful.
The only direct improvement I have to suggest is maybe indicate that the end-to-end latency calculation is an estimate, not a hard mathematical reality. "You can estimate the total end-to-end latency by adding..."
closes #14942
preview