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.

Sign up for GitHub

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

Jump to bottom

Wrong response time for pgsql #160

Closed
tsg opened this issue Jun 10, 2015 · 0 comments
Closed

Wrong response time for pgsql #160

tsg opened this issue Jun 10, 2015 · 0 comments
Assignees
@tsg
Labels
bug

Comments

@tsg
Copy link
Contributor

tsg commented Jun 10, 2015

I noticed that the response time is wrongly captured when following these steps:

  • start the pgsql shell
  • wait a little
  • do a select query

expected:

  • the response time for the select query should be below 2-3 ms

happens:

  • the response time captured is around 1-2 seconds. It looks like the time is measured from the time the connection is established.
@tsg tsg self-assigned this Jun 12, 2015
tsg pushed a commit that referenced this issue Jun 12, 2015
When using the topspeed flag, simply use the timestamp from the packets.
04fff5b 
This makes the responsetime fields deterministic in integration tests.
Needed for a test in #160.
@tsg tsg closed this as completed in 7aeef3d Jun 12, 2015
andrewkroh added a commit that referenced this issue Dec 2, 2015
@andrewkroh
Merge pull request #160 from ruflin/libbeat-update
05b09e4 
Update to most recent version of libbeat.
tsg pushed a commit to tsg/beats that referenced this issue Jan 20, 2016
When using the topspeed flag, simply use the timestamp from the packets.
a8996dd 
This makes the responsetime fields deterministic in integration tests.
Needed for a test in elastic#160.
tsg pushed a commit to tsg/beats that referenced this issue Jan 20, 2016
Correctly ignore command types we don't understand.
55fd7d1 
We used to glue packets together waiting for one that we understand,
but one side effect was that we pick the wrong start time for the
transaction. This fixes elastic#160.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tsg tsg

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@tsg