Skip to content
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

cli: show client-server latency on startup of interactive sql connection #50250

Closed
wants to merge 1 commit into from

Conversation

arulajmani
Copy link
Collaborator

Previously, we did not show client-server latency for interactive sql
connections. Now, a line is printed at the top when an interactive sql
session begins which prints the client-server latency. Latency is
measured by the time it takes the "get cluster version" query to return.

Addresses #49450

Release note (cli change): cli now prints the client-server latency on
startup.

Previously, we did not show client-server latency for interactive sql
connections. Now, a line is printed at the top when an interactive sql
session begins which prints the client-server latency. Latency is
measured by the time it takes the "get cluster version" query to return.

Addresses cockroachdb#49450

Release note (cli change): cli now prints the client-server latency on
startup.
@arulajmani arulajmani requested a review from solongordon June 16, 2020 00:11
@arulajmani arulajmani requested a review from a team as a code owner June 16, 2020 00:11
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Contributor

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked into this into the context of the original issue.
I think in the commit message / PR description you can't yet write "Addresses" but instead "Informs"

(Also, nit: github has magic words to auto-close a linked issue; the words include "Fixes" or "Closes" but not "Addresses". You recognize a magic words when it gets underlined on the web display.)

Now at a higher level I think you're not being ambitious enough in this PR. The original issue makes several points which I think you can achieve here:

  1. display the time to receive the 1st row of result separately from the time to receive the last row, and possibly separately to the time to finish the display. The client has all 3 timestamps and we could enhance our time display to inform the user.

  2. regarding server-side execution latency. This information could be stored server-side, and retrieved by a statement. Look into the implementation of SHOW SYNTAX and SHOW TRANSACTION STATUS (the "observer statements"). You could add another one which observes the execution time of the last executed statement before it. Then you could modify the shell to issue that new observer statement immediately after a statement execution completes. Then we'd get exactly what Alex is requesting, and you wouldn't even need to report the client-server roundtrip latency at the beginning of the session.

@@ -278,6 +281,7 @@ func (c *sqlConn) checkServerMetadata() error {
}
}
}
fmt.Printf("# Client-server latency: %s\n", latency)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add "roundtrip" here which is what you're measuring.

@solongordon
Copy link
Contributor

Seconding @knz here. I think displaying the client-server latency is of limited value compared to exposing the actual server-side latency, from parsing the query to returning the first row. If this is possible via "observer" statements that would be great.

@arulajmani
Copy link
Collaborator Author

Thanks for the suggestions @knz. I especially like the second option, and I think it seems doable.

Side note: My intention with this PR was to knock out the easy/quick patch and then iterate from there to tackle individual queries. That's why I wrote addresses in my PR instead of fix, though I agree writing informs would have made my intention clearer.

@arulajmani
Copy link
Collaborator Author

I'm closing this for now; once the observer statement goes in, I'll change my approach and re-open a PR.

@arulajmani arulajmani closed this Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants