These are chat archives for ManageIQ/manageiq/performance

Oct 2016
Keenan Brock
Oct 26 2016 01:45
I'll get some numbers for other screens, but does look like the newer ancestry gem is quite a bit faster. ManageIQ/manageiq#12190
One screen that does use ancestry quite a bit is 85% faster. (of note, cap&u and others that use blue_folder_parent are going to be quite a bit faster)
Keenan Brock
Oct 26 2016 02:52
ugh. comparing something as simple as ancestry between '0' and '00' vs ancestry = '0' OR ancestry like '0/%' and adding a possible ancestry varchar_pattern_ops index is just so confusing.
Have visited this comparison ~4 times over the past year and a half. and once I feel like I'm making some good progress, I get confused from the results.
I mean it is only 4 permutations (2 boolean variables) - but either I forget to vacuum or something and then I end up more confused than when I start.
But one thing for certain, like vs ilike (changes made in new ancestry gem) is definitely 20-80% faster. (depending upon the number of ancestry queries
Jason Frey
Oct 26 2016 12:51
Would 4 separate databases be easier?
Also, out of curiosity, is it the iLike change specifically that makes it faster or could it be something else the gem update that came along for the ride?
Also also, what are some example timings (I.e. 80% on 30s is more impactful than 80% on 1s)
Keenan Brock
Oct 26 2016 13:46
@Fryguy ilike specificially is most of the benefit
I put in 2 different timing examples in that PR. Do you want more?
the difference for that impact is based upon the number of relationship queries
Dennis Metzger
Oct 26 2016 13:52
think its a tell me total time not just the % difference.
Jason Frey
Oct 26 2016 14:47
I was more asking if you had any other examples that weren't directly in that PR
Like other pages that happened to be faster
Keenan Brock
Oct 26 2016 15:29

@Fryguy aah - yea, any page or process that uses folders / relationships should get a boost.

I have no other examples. the vms explorer was a bonus win.

fyi - I added ManageIQ/manageiq#12207 which uses operator indexes. it should make ancestry queries quite a bit faster. (removes most of the winnings we got from the ilike vs like fix)
I had hoped that using "between '#{child_ancestry}' and '#{child_ancestry}0'" would have yielded better results, but that index is the way we want to go in the future.