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

ProfileResult and CollectorResult should print machine readable timing information #22638

Merged
merged 2 commits into from Jan 16, 2017

Conversation

Projects
None yet
3 participants
@cbuescher
Member

cbuescher commented Jan 16, 2017

Currently both ProfileResult and CollectorResult print the timing field in a
human readable string format (e.g. "time": "55.20315000ms"). When trying to
parse this back to a long value, for example to use in the planned high level
java rest client, we can lose precision because of conversion and rounding
issues. This change introduces the additional field time_in_nanos that prints
the raw timing value in nanoseconds.

ProfileResult and CollectorResult should print machine readable timin…
…g information

Currently both ProfileResult and CollectorResult print the timing field in a
human readable string format (e.g. "time": "55.20315000ms"). When trying to
parse this back to a long value, for example to use in the planned high level
java rest client, we can lose precision because of conversion and rounding
issues. This change introduces the additional field `time_in_nanos` that prints
the raw timing value in nanoseconds.
@cbuescher

This comment has been minimized.

Member

cbuescher commented Jan 16, 2017

This is a follow up to #22561 against the 5.x branch. Here we want to keep the old "time" field format and always add the addtional "time_in_nanos" field. Adding a note to the docs that the time field will not be printed by default anymore with the next major version.

of all children.
The `"breakdown"` field will give detailed stats about how the time was spent, we'll look at
that in a moment. Finally, the `"children"` array lists any sub-queries that may be present. Because we searched for two
values ("search test"), our BooleanQuery holds two children TermQueries. They have identical information (type, time,
breakdown, etc). Children are allowed to have their own children.
NOTE: The `"time"` field is only intended for human consumption. If you need exact timing values use `"time_in nanos"`. The `"time"`

This comment has been minimized.

@javanna

javanna Jan 16, 2017

Member

does it make sense to have the field names between both backticks and double quote?

This comment has been minimized.

@cbuescher

cbuescher Jan 16, 2017

Member

I'm only following the way the field names are written in the previous paragraph here. It's not completely consitent in this part of the docs I think. Not sure if I should make this change bigger by changing it one way or the other in the whole document?

This comment has been minimized.

@javanna

javanna Jan 16, 2017

Member

I hand't noticed, don't bother, fine with me as-is

This comment has been minimized.

@clintongormley

clintongormley Jan 17, 2017

Member

I'd prefer just backticks - it's what we do in the rest of the docs

This comment has been minimized.

@cbuescher

cbuescher Jan 17, 2017

Member

@clintongormley okay, I opened #22653 doing this the profile documentation.

of all children.
The `"breakdown"` field will give detailed stats about how the time was spent, we'll look at
that in a moment. Finally, the `"children"` array lists any sub-queries that may be present. Because we searched for two
values ("search test"), our BooleanQuery holds two children TermQueries. They have identical information (type, time,
breakdown, etc). Children are allowed to have their own children.
NOTE: The `"time"` field is only intended for human consumption. If you need exact timing values use `"time_in nanos"`. The `"time"`
field is currently printed by default, but this will change with the next major version where `"time_in_nanos"` will be

This comment has been minimized.

@javanna

javanna Jan 16, 2017

Member

shall we state what the next major version is? 6.0.0 ?

This comment has been minimized.

@cbuescher
of all children.
The `"breakdown"` field will give detailed stats about how the time was spent, we'll look at
that in a moment. Finally, the `"children"` array lists any sub-queries that may be present. Because we searched for two
values ("search test"), our BooleanQuery holds two children TermQueries. They have identical information (type, time,
breakdown, etc). Children are allowed to have their own children.
NOTE: The `"time"` field is only intended for human consumption. If you need exact timing values use `"time_in nanos"`. The `"time"`
field is currently printed by default, but this will change with the next major version where `"time_in_nanos"` will be
printed by default. The `"time"` field needs to be switched on by using the `?human=false` <<common-options, common options>> flag then.

This comment has been minimized.

@javanna

javanna Jan 16, 2017

Member

I think this last sentence may be confusing as it's about how to migrate to 6.0.0. That should only be in the 6.0.0 migrate guide I think.

This comment has been minimized.

@cbuescher
@javanna

left a couple of comments in docs, LGTM otherwise

@cbuescher cbuescher merged commit 056e2f7 into elastic:5.x Jan 16, 2017

1 check passed

CLA Commit author is a member of Elasticsearch
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment