Statistics collected in query response time tables are incorrect
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Won't Fix
|
Medium
|
Unassigned | |||
5.6 |
Triaged
|
Medium
|
Unassigned | |||
5.7 |
Triaged
|
Medium
|
Unassigned |
Bug Description
Query Response Time feature/plug-in provides aggregated query response time metrics through a series of tables. By definition response time is the entire time it takes a system to react to a given input, which in this case is a database query started by a user or an application. However, it's not what query_response_time tables collect and aggregate.
Depending on Percona Server version, the times sent for aggregation are collected in the following ways:
1. QRT plug-in in MySQL 5.6+
static void query_response_
{
..
query_
2. Built-in QRT in MySQL 5.5 ==
static inline ulonglong get_query_
{
..
res= cur_utime - thd->utime_
..
return res;
}
void log_slow_
{
..
ulonglong query_exec_time= get_query_
#ifdef HAVE_RESPONSE_
if (opt_query_
{
query_
}
#endif
In both cases query response time is calculated as a timestamp difference between the query end (end_utime_
1. Time spent in MDL contributes as much to query response time as anything else.
2. InnoDB implements thd_storage_
This means, contrary to their names, the query_response_time tables do not actually provide any information about query response times.
tags: | added: query-response-time |
Your observation is correct. It looks like it was implemented this way to match the slow query log behavior, which BTW also raises questions for the users: https:/ /bugs.mysql. com/bug. php?id= 71767, https:/ /bugs.mysql. com/bug. php?id= 65139.
The current behavior should be documented and then switch to full query time (controlled by option or just by default) should be planned too.