These are chat archives for ManageIQ/manageiq/performance

11th
Jan 2016
Alex Krzos
@akrzos
Jan 11 2016 13:25
@kbrock I'll be investigating perf_capture_timer on 5.5 running much slower compared to 5.4 later today.. if I can get my lab back up, power was lost over the weekend ugh
Keenan Brock
@kbrock
Jan 11 2016 13:25
ugh
Dennis Metzger
@dmetzger57
Jan 11 2016 13:26
so performance in the lab was extremely poor over the weekend :smile:
Alex Krzos
@akrzos
Jan 11 2016 13:28
yeah apparently there was a fire and rh tower is on generator power
rather than street power
akrzos @akrzos can't wait to find a corrupted database
Daniel Berger
@djberg96
Jan 11 2016 14:52
sys-proctable 1.0.0 released into the wild, now with smaps!
(pay no attention to the version number, i simply ran out of numbers, it's not a major release)
Jason Frey
@Fryguy
Jan 11 2016 15:32
I didn't know one could run out of numbers
Daniel Berger
@djberg96
Jan 11 2016 15:36
Get yours today while supplies last!
Oleg Barenboim
@chessbyte
Jan 11 2016 16:03
how do you run out of numbers? what does that even mean?
Daniel Berger
@djberg96
Jan 11 2016 16:44
It means I was at 0.9.9.
And I hate teeny versions.
Oleg Barenboim
@chessbyte
Jan 11 2016 16:44
yes, but jumping to 1.0.0 is a MAJOR thing, whereas going to 0.9.10 is very minor
Jason Frey
@Fryguy
Jan 11 2016 16:56
I know your gem isn't SemVer, but according to SemVer it would have gone to 0.10.0
Daniel Berger
@djberg96
Jan 11 2016 16:59
Well, sorry if I caused any grief.
Jason Frey
@Fryguy
Jan 11 2016 17:04
not really a problem, I was just confused by the "ran out of numbers" part :D
Daniel Berger
@djberg96
Jan 11 2016 17:05
I was being facetious. Really, I just decided to declare it 1.0.0, because I wanted to. :)
BTW, did any of you have any issues reading the UserEventAgent process on your macs?
(using sys-proctable I mean)
Jason Frey
@Fryguy
Jan 11 2016 17:12
nope, never saw that one personally
Daniel Berger
@djberg96
Jan 11 2016 17:16
ok, good. i suspect that guy isn't actually using the latest version somehow, maybe an rvm thing.
Jason Frey
@Fryguy
Jan 11 2016 17:17
maybe rubinius :trollface:
Daniel Berger
@djberg96
Jan 11 2016 17:19
rubinius...haven't looked at that in a very long time.
Keenan Brock
@kbrock
Jan 11 2016 18:31
@akrzos when you have perf_capture_timer issues, could you puts [Host, MiqTask, MiqQueue].map(&:count) ? thanks (get the counts for each of those tables - can do from psql if you prefer)
Alex Krzos
@akrzos
Jan 11 2016 20:28
@kbrock
[root@CF-Scale-R0002-Wkr01 vmdb]# bundle exec bin/rails c
Loading production environment (Rails 4.2.5)
irb(main):001:0> puts [Host, MiqTask, MiqQueue].map(&:count)
200
886
5911
=> nil
akrzos @akrzos pulls timing values
Keenan Brock
@kbrock
Jan 11 2016 20:28
thanks
We do hot have MiqTask indexed. wonder what difference that will make
Alex Krzos
@akrzos
Jan 11 2016 20:31
Here is 5.4 values I have:
[----] I, [2016-01-11T14:21:01.084821 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:27:17.916257 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T14:27:17.916870 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039475498], State: [ok], Delivered in [376.840429762] seconds
[----] I, [2016-01-11T14:29:57.241466 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:35:30.089465 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T14:35:30.089722 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039481043], State: [ok], Delivered in [332.854323624] seconds
[----] I, [2016-01-11T14:35:56.922326 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:40:50.559153 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T14:40:50.559378 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039481960], State: [ok], Delivered in [293.649137022] seconds
[----] I, [2016-01-11T14:42:02.051579 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:48:24.137486 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T14:48:24.137737 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039482253], State: [ok], Delivered in [382.093244142] seconds
[----] I, [2016-01-11T14:51:01.429196 #2644:11cfe98]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:59:56.775564 #2644:11cfe98]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T14:59:56.775914 #2644:11cfe98]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039485257], State: [ok], Delivered in [535.352771214] seconds
[----] I, [2016-01-11T15:00:02.161921 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T15:08:08.684704 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T15:08:08.684927 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039489337], State: [ok], Delivered in [486.531172424] seconds
[----] I, [2016-01-11T15:08:58.324643 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T15:14:33.104182 #2647:cb5e94]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...Complete
[----] I, [2016-01-11T15:14:33.104380 #2647:cb5e94]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039492040], State: [ok], Delivered in [334.801984293] seconds
[----] I, [2016-01-11T15:14:58.560030 #2644:11cfe98]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T15:24:59.581118 #2644:11cfe98]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [1000039494607], State: [timeout], Delivered in [601.113872941] seconds
crud, I should cut that down
But for comparsion purposes, here's my 5.5 environment:
[----] I, [2016-01-10T13:31:45.635814 #8521:4d3988]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-10T14:31:46.015474 #8521:4d3988]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001273297], State: [timeout], Delivered in [3600.386883069] seconds
[----] I, [2016-01-10T14:34:47.095985 #47834:c0d988]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-10T15:34:47.115371 #47834:c0d988]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001291392], State: [timeout], Delivered in [3600.027402111] seconds
[----] I, [2016-01-10T15:34:52.744959 #9371:111b998]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-10T16:34:52.828783 #9371:111b998]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001309678], State: [timeout], Delivered in [3600.093490664] seconds
[----] I, [2016-01-10T16:37:55.822662 #36989:114b990]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-10T17:37:55.852903 #36989:114b990]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001327518], State: [timeout], Delivered in [3600.036974685] seconds
[----] I, [2016-01-10T17:40:58.509522 #20294:33d998]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-10T18:40:58.583286 #20294:33d998]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001345079], State: [timeout], Delivered in [3600.080513684] seconds
[----] I, [2016-01-10T18:44:01.190659 #24534:a81998]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T10:05:04.330306 #3031:f63998]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T11:08:12.024094 #3041:81798c]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T12:08:12.055479 #3041:81798c]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001393083], State: [timeout], Delivered in [3600.037420736] seconds
[----] I, [2016-01-11T12:11:13.922048 #3034:f7998c]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T13:11:14.572452 #3034:f7998c]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001410871], State: [timeout], Delivered in [3600.656224517] seconds
[----] I, [2016-01-11T13:11:17.123613 #3038:1035998]  INFO -- : MIQ(Metric::Capture.perf_capture_timer) Queueing performance capture...
[----] I, [2016-01-11T14:11:17.188530 #3038:1035998]  INFO -- : MIQ(MiqQueue#delivered) Message id: [2000001428832], State: [timeout], Delivered in [3600.077610085] seconds
Keenan Brock
@kbrock
Jan 11 2016 20:32
that's not so good
Alex Krzos
@akrzos
Jan 11 2016 20:32
Note I edited the scheduler file to assign a timeout of 3600s to perf_capture_timer
I thought it was because I overcommitted the piece of hardware last week
An absolutely huge order of difference there
Keenan Brock
@kbrock
Jan 11 2016 20:33
you still concerned about perf_capture_timer being slow, mor mostly running it?
wait - this is running perf_capture_timer?
Alex Krzos
@akrzos
Jan 11 2016 20:33
Well concerned that it has slowed down in 5.5
thats pulled from the logs
so thats off a "live" environment
bith 5.4 and 5.5 connected to the extra-large vmware environment
Keenan Brock
@kbrock
Jan 11 2016 20:34
when you are done with the capture, I'd like to locally run perf_capture_timer -
it will probably botch your timing results
let me know when you are done with it
point my code at your DB
if that is ok
Alex Krzos
@akrzos
Jan 11 2016 20:35
should
I'll pm you the ip address
Keenan Brock
@kbrock
Jan 11 2016 20:35
thanks
Jason Frey
@Fryguy
Jan 11 2016 20:38
there is a BZ for that issue
Keenan Brock
@kbrock
Jan 11 2016 20:38
+1
Jason Frey
@Fryguy
Jan 11 2016 20:38
ok, wasn't sure you knew about it or not
Keenan Brock
@kbrock
Jan 11 2016 20:38
thanks so much though
tail spin != fun
Jason Frey
@Fryguy
Jan 11 2016 20:39
I thought you had fixed it already, but maybe that was a different purge spiral :/
Keenan Brock
@kbrock
Jan 11 2016 20:39
:)
it is the purge that has been cut down
this is simply asking "would you run performance"
Jason Frey
@Fryguy
Jan 11 2016 20:40
yeah
Keenan Brock
@kbrock
Jan 11 2016 20:40
there is a PR in there that is trying to fix this one
Jason Frey
@Fryguy
Jan 11 2016 20:40
k
Keenan Brock
@kbrock
Jan 11 2016 20:40
ManageIQ/manageiq#5941
that is part one
so we don't bring back tons of Queue records just to display a status
ooh - the one to fix purge hasn't been merged yet either :( ManageIQ/manageiq#5924 / ManageIQ/manageiq#5925
Keenan Brock
@kbrock
Jan 11 2016 21:09
@matthewd @jrafanie @Fryguy this preload stuff. Is it smart? I notice the queries generated are different from the standard rails queries. and they seem to be hitting the database with the same queries over and over again.
Jason Frey
@Fryguy
Jan 11 2016 21:15
preload is the basis for AR::Relation#includes, so yeah, it's smart
Keenan Brock
@kbrock
Jan 11 2016 21:15
I dunno
guess I'll have to do a socraties on it and prove where it is dumb
Matthew Draper
@matthewd
Jan 11 2016 21:16
I don't know whether it uses the query cache, or does something that bypasses it
Jason Frey
@Fryguy
Jan 11 2016 21:16
query cache would only be in a controller request though, right?
a worker doing something won't have the query cache
Keenan Brock
@kbrock
Jan 11 2016 21:17
looking at what is going over the wire, I almost think that not reloading and going n+1 would be faster
pessimism / not really / but you get the idea
yea - the number of times it is loading this same folder is ridiculous
... and all the relationships below it
Matthew Draper
@matthewd
Jan 11 2016 21:20
Is that the fault of the preloader though, or the thing calling it / something getting refresh-happy on the already-loaded relations?
Keenan Brock
@kbrock
Jan 11 2016 21:20
possibly
maybe this is something as simple as setting a reverse relationship back to an ems
Matthew Draper
@matthewd
Jan 11 2016 21:21
I'm not following how we get from "we're doing more work than required" —> "this specific thing is dumb"
The first part is known: that's why we have a performance room :)
Keenan Brock
@kbrock
Jan 11 2016 21:21
ok
I'll hit the thesaurus for dumb
if you run preload on the some object 3 different times, will it leverage the sql cache and not reload it. or will it hit the database multiple times
also the fact that it generates in clauses for a single id makes me wonder how much of the standard infrastructure is being used
Jason Frey
@Fryguy
Jan 11 2016 21:23
preload uses the internal relation cache the same way it does for any relation call
if the relation is already loaded it won't load it again
Keenan Brock
@kbrock
Jan 11 2016 21:23
ok. well I'm not totally seeing that. there must be something else our code is doing to confuse it
@Fryguy well on the same object
Matthew Draper
@matthewd
Jan 11 2016 21:24
I'd argue that it should use an in clause, but that's probably a matter for rails anyway
Jason Frey
@Fryguy
Jan 11 2016 21:24
it might be creating a dynamic relation and thus cannot (or perhaps can no longer) leverage the loaded relation
Keenan Brock
@kbrock
Jan 11 2016 21:24
but if 2 different vms point to a different ems object (same id) - it seems to hit the database twice
Matthew Draper
@matthewd
Jan 11 2016 21:24
Yeah, that's how activerecord works
Keenan Brock
@kbrock
Jan 11 2016 21:24
well - it runs the query twice
but the sql cache just returns the same values- but doesn't hit the db - right?
Jason Frey
@Fryguy
Jan 11 2016 21:25
can you give a 5 line example for console so we can verify?
Matthew Draper
@matthewd
Jan 11 2016 21:25
You're the one looking at the thing
Keenan Brock
@kbrock
Jan 11 2016 21:25
good idea
yes. I can test this easily enough - thanks
(and thanks for the polite RTFM / STFU)
Jason Frey
@Fryguy
Jan 11 2016 21:27
@matthewd does calling GC.start do a full GC (across all generations?) or does it only do the minimum?
if the latter, is there a way to GC all generations?
Matthew Draper
@matthewd
Jan 11 2016 21:27
I think last time I looked, I experimentally determined it seemed to always do a major
Jason Frey
@Fryguy
Jan 11 2016 21:27
ok cool
@mkanoor is testing some automate-GC thing and is injecting GC.starts to verify, but we weren't sure it was working or not :)
Matthew Draper
@matthewd
Jan 11 2016 21:28
You can check GC.stat(:major_gc_count) to be sure
Jason Frey
@Fryguy
Jan 11 2016 21:29
ok thanks
Keenan Brock
@kbrock
Jan 11 2016 21:33
example of my statement about not hitting the cache:
  MiqServer Load (50.2ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.1ms - 1rows)
  Configuration Load (48.9ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (56.7ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.1ms - 1rows)
  Configuration Load (48.1ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (60.1ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.1ms - 1rows)
  Configuration Load (47.1ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (101.6ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.2ms - 1rows)
  Configuration Load (47.6ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (74.8ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.2ms - 1rows)
  Configuration Load (47.6ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (62.1ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
  MiqServer Inst Including Associations (0.4ms - 1rows)
  Configuration Load (46.6ms)  SELECT  "configurations"."updated_on" FROM "configurations" WHERE "configurations"."miq_server_id" = $1 AND "configurations"."typ" = $2  ORDER BY "configurations"."id" ASC LIMIT 1  [["miq_server_id", 2000000000002], ["typ", "vmdb"]]
  Configuration Inst Including Associations (0.1ms - 1rows)
  MiqServer Load (48.3ms)  SELECT  "miq_servers".* FROM "miq_servers" WHERE "miq_servers"."guid" = $1 LIMIT 1  [["guid", "d0a23488-b4bb-11e5-bf83-001a4a22390c"]]
Matthew Draper
@matthewd
Jan 11 2016 21:35
@kbrock that looks like an N+1 to me… you're claiming that's happening inside a preload?!
Keenan Brock
@kbrock
Jan 11 2016 21:35
no
turns out it hadn't gotten to the preloader yet
question
is that an N+1
it is the same results over and over again
doesn't rails have something to prevent that?
Jason Frey
@Fryguy
Jan 11 2016 21:36
It may not be, depending on the context
Matthew Draper
@matthewd
Jan 11 2016 21:36
As for the query cache… I'm not certain, but I think that spelling suggests it's not being used. But I guess that's what @Fryguy mentioned about it only being conditionally active.
Jason Frey
@Fryguy
Jan 11 2016 21:36
most config stuff is cached globally for 5 minutes
Matthew Draper
@matthewd
Jan 11 2016 21:36
No, Rails does not have something to prevent that
That is an ordinary N+1
Jason Frey
@Fryguy
Jan 11 2016 21:36
Honestly, skip config performance right now unless you can narrow down to a specific N+1
because I am hoping config revamp just makes that :sparkles: go away :sparkles:
Keenan Brock
@kbrock
Jan 11 2016 21:37
well, the config is showing up because it looks up the same miq_server over and over
yea - I'm not trying to go anywhere near config
Jason Frey
@Fryguy
Jan 11 2016 21:37
is it calling MiqServer.my_server?
(and if so, is it passing true?)
Keenan Brock
@kbrock
Jan 11 2016 21:38
possibly
Jason Frey
@Fryguy
Jan 11 2016 21:38
MiqServer.my_server is cached for 5 minutes
but passing true does a forced reload
Keenan Brock
@kbrock
Jan 11 2016 21:38
that does look like a MiqServer.my_server(true)
Jason Frey
@Fryguy
Jan 11 2016 21:38
ugh, if that can be avoided, we should, but that usage is very context depedent
Keenan Brock
@kbrock
Jan 11 2016 21:40
fun - lib/vmdb/config.rb config_mtime_from_db calls MiqServer.my_server(true)
thanks
Jason Frey
@Fryguy
Jan 11 2016 21:41
yeha, just avoid that file at all costs :D
Keenan Brock
@kbrock
Jan 11 2016 21:41
I had thought that if you do a Ems.find_by_id(1) many times, it would create the objects, but not hit the db
Jason Frey
@Fryguy
Jan 11 2016 21:41
no, that will always hit the db
Keenan Brock
@kbrock
Jan 11 2016 21:41
I'll find out if perf_capture_timer is looking for a configuration value somewhere
Jason Frey
@Fryguy
Jan 11 2016 21:41
that is sort of what I was saying about not leveraging the relation cache
.find_by_id is a new relation every time
Keenan Brock
@kbrock
Jan 11 2016 21:43
is there a way to "preload" with local records?
ems = Ems.first
vms = Ems.vms.all.to_a
vms.map { |vm| vm.ems = ems }
I know in this exact example, you can do a trick on vms so they are pre-assigned ems... but talking a different case - example for simplicity
Jason Frey
@Fryguy
Jan 11 2016 21:43
I think that's the inverse_of you're looking for there?
Keenan Brock
@kbrock
Jan 11 2016 21:44
yes, that exact case, inverse_of is perfect. but for these, that array is coming back from a ruby method returning gook
looking at perf_rollup_parents
Jason Frey
@Fryguy
Jan 11 2016 21:45
preload is for doing something like .includes but after you've already queried
Keenan Brock
@kbrock
Jan 11 2016 21:45
yea - know how to do that. but what if you have a bunch of objects, and you know the relation in them. and you want to set it
and don't want to change the code to pass around a hash indexed by id
Jason Frey
@Fryguy
Jan 11 2016 21:46
e.g.:
vms = ems.vms.select { |vm| vm.name =~ /microsoft/ } # don't want to preload here with .includes because we want to filter
MiqPreloader.preload(vms, :host)
vms.each { |vm| vm.host } # prevents the N+1 here
Keenan Brock
@kbrock
Jan 11 2016 21:46
ok. that works - cool
Jason Frey
@Fryguy
Jan 11 2016 21:46
I think inverse_of should handle those cases, except in polymorphic case
Keenan Brock
@kbrock
Jan 11 2016 21:47
well, most of this code looks like:
vms = Vm.where()
MiqPreloader.preload(vms, :ems) # will try this
Jason Frey
@Fryguy
Jan 11 2016 21:47
yeah, that's fine
and it will only bring back the minimum number of EMS objects; even if 1000 VMs all point to 1 EMS, it will only bring back 1 EMS object (so, it's smart)
also, i know your example is contrived, but you could just tack on .includes(:ems) there on the where clause (though I assume you can't in the real case)
Matthew Draper
@matthewd
Jan 11 2016 21:50
The answer to your direct question is no.. but as explored above, much of the time you shouldn't need to
Keenan Brock
@kbrock
Jan 11 2016 21:50
yea. thanks
can't use includes here