These are chat archives for ManageIQ/manageiq/performance

18th
Nov 2016
Nick LaMuro
@NickLaMuro
Nov 18 2016 14:11
@Fryguy regarding the Yaml, a when you bring down the TimeProfile, it will deserialize the profile column (which is a yaml serialized hash)
Jason Frey
@Fryguy
Nov 18 2016 14:12
not immediately, but we probably deserialize to get at the :tz pretty much right away anyway
Nick LaMuro
@NickLaMuro
Nov 18 2016 14:12
We could avoid that if we could do it all in SQL, but it isn't possible because most of the comparisons are on the "day" methods
Jason Frey
@Fryguy
Nov 18 2016 14:12
right
mind you, I'm not saying YAML isn't bad, but I am balancing the performance impact of that versus calling it 200,000 times more than it's supposed to be called
on a table with literally 7 rows, I don't think we should focus our efforts there
really nice find, btw :D
@NickLaMuro where is the primary loop located...couldn't tell from your PR
ohhhh...right we also have multiple-region issues at play here
Nick LaMuro
@NickLaMuro
Nov 18 2016 14:16
Yup
Jason Frey
@Fryguy
Nov 18 2016 14:16
is this database you were playing with a global region?
Keenan Brock
@kbrock
Nov 18 2016 14:17
yes
Jason Frey
@Fryguy
Nov 18 2016 14:17
ah yeah...I see it now in the description
Keenan Brock
@kbrock
Nov 18 2016 14:20
re yaml: if timeprofiles were sql friendly, you could aggregate metrics properly in the database vs bringing back every row and then finding the max in ruby
yes, it would not fix the time profile issue for these searches, but the yaml is causing issues around a few aspects in our current report
Jason Frey
@Fryguy
Nov 18 2016 14:21
I still don't see why you can't do that
Looking up the TimeProfile itself, sure, uses the serialized column
but on metrics_rollups it's a simple where clause
unless you are talking about the yaml on the metrics_rollups?
Otherwise I would expect it's just .where(:time_profile_id = tp.id).max(:cpu_usage_rate_average) or whatever (I forget the syntax for SELECT MAX())
Keenan Brock
@kbrock
Nov 18 2016 14:27
yea, those issues are probably a tangent to the yaml. I'm conflating.
Those are tricky because there are so many meta columns and ruby meta magic at play here.
but it is solvable
Keenan Brock
@kbrock
Nov 18 2016 14:33
@NickLaMuro this is what I run on reports to determine if the columns are good
think that assums it is running in manageiq/
at the time I was trying to determine "are all the columns in the reports (includes, sort, cols) matching up"
but this is good now because it lets us know which columns are forcing a ruby query. which will probably be the case for this report
I'll have to spruce this up and get it into our scripts directory