MySQL Latency graph fluctuations

[drupaladmin]

The MySQL Latency graph can exhibit significant fluctuations even when there are no changes within the system.

[Esysteme]

The problem is on your query, you consider each type of query individually, so if one user make 2 or 3 queries longest than your value only one time, it's fuck your latency, your should include the COUNT_STAR * AVG_TIMER_WAIT / COUNT_STAR then group by each range and count 95%.

[kochetovd]

@Esysteme Please clarify what did you mean by the expression COUNT_STAR * AVG_TIMER_WAIT / COUNT_STAR?
it is equal to AVG_TIME_WAIT, which is used in the current latency calculation.

[Esysteme]

no because in your system, you take all query with same value.

but few queries you executed only once can totally fuck you time response, and their not representative of queries executed on your server. that's why need to take the number of execution in consideration.

Imagine you have one query, the most executed on your server, more than all others. you optimized her of 25%; it's will be totally a game changer for your server. but with your query we will not be able to see it.

i will publish mine later (but will be without 95 percentil) when i back on my computer

[drupaladmin]

@Esysteme We've fixed this problem by calculating the latency on the platform side every minute for all queries executed during that time.

The root cause of the issue was that we calculated aggregated Latency since server restart.