-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Non-optimal app layer iteration in MetricRepository #1900
Comments
We're open to PRs. We have 200,000 entries on https://status.styleci.io/, and it is not exactly fast. :P |
Counting this as a bug. We'd love a PR for 2.3 :) |
Happy to oblige |
Thanks! Please let us know if we can help you. |
@deanstalker did you get anywhere with this? |
I was sanctioned to work on a PR in company time a few weeks ago, however paid work means it was on the back burner for a few days. I managed to get the MySQL and Sqlite repository classes updated, and have just been waiting to get the Postgres one updated ... Meanwhile I have seen #1971, and its along similar lines |
Awesome! Well, if you can, I'd love to see the work you've done and look at merging both together. |
Before submitting your issue, please make sure that you've checked all of the checkboxes below.
php -v
rm -rf bootstrap/cache/*
from the root of your Cachet installation.To help us better understand your issue, please answer the following — cheers!
Your setup
Expected behaviour
Iterating over the metric points should be quite performant.
Actual behaviour
I've noticed in the MetricRepository you are iterating over each minute/hour in the app layer - which will potentially generate between 12 - 60 queries of an average return time of 4-8 seconds each - depending on the data size.
Subsequently, we're seeing our MySql process jump to 100% CPU time once the Metric Points table gets close to 40,000 records
Wouldn't it be more performant to iterate this in the query itself? ie.MySql example
SELECT AVG(mp.value * mp.counter) AS value FROM metrics m INNER JOIN metric_points mp ON m.id = mp.metric_id WHERE m.id = 1 AND DATE_SUB(curdate(), INTERVAL 12 HOUR) <= mp.created_at GROUP BY HOUR(mp.created_at)
The text was updated successfully, but these errors were encountered: