- Notifications
You must be signed in to change notification settings - Fork905
docs: add a section about latency and how it's measured#16734
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
fb514c1 tod19839fComparethis 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Coder server or workspace proxy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
updated to
The Coder UI measures round-trip time to the Coder server+ or workspace proxyusing 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 toworkspace-proxies.md in9e7dc7b
I also force-pushed to this branch because I repointed it tomain 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
-**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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 outnot direct P2P connections or should we cut that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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..."
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
About the best we can hope for given the state of the product!
43d584c intomainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
closes#14942
preview