Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Joe Rafaniello
    @jrafanie
    I might have missed it, have we done comparisons of master to 5.4?
    I haven't yet migrated to master... I'm wondering if it's worth doing that
    @kbrock looks like a valid test failure on your rbac.search sort fix: https://travis-ci.org/ManageIQ/manageiq/jobs/106761189
    Dennis Metzger
    @dmetzger57
    @jrafanie @akross has run 5.4.4.2, 5.4.5.0 and 5.5.0.13 with the customer database. results in BZ 1281999. The number are better on 5.5.0, on the Haswell hardware the page loads in 12-17 seconds as opposed to 27-20 wih 5.4.42 and on Sandy Bridge its 21-27 seconds vs 49-63 seconds. Master to be tried. I’ve asked if the times on 5.5.0 would be acceptable, though I’ve been told that an upgrade is not viable in the short term.
    Keenan Brock
    @kbrock
    @jrafanie thanks for the reminder
    Joe Rafaniello
    @jrafanie
    np
    Joe Rafaniello
    @jrafanie
    @dmetzger57 @akrzos in the comments regarding the timing in the bugzilla, https://bugzilla.redhat.com/show_bug.cgi?id=1281999#c21, is that the initial visit to vm_infra/explorer and is that from the rails log/production.log?
    Keenan Brock
    @kbrock
    the initial visit has a bunch of junk in there - including that one part that you mentioned lj
    Joe Rafaniello
    @jrafanie
    Yeah, I can't tell what the numbers mean
    Keenan Brock
    @kbrock
    I'd prefer to ignore the first, and just look at the others
    yea
    Dan Clarizio
    @dclarizio
    @chessbyte We could not build the second and third accordion trees until clicked on, but then those should NOT be the ones taking all the time as those are just trees of filters (maybe dozens) not thousands like the VM & Templates tree, which mimics the VMware hierarchy. That first tree is the biggest offender in large environments.
    Alex Krzos
    @akrzos
    @jrafanie Yes thats from the production.log
    The initial visit to the explorer is the first timing
    (always higher)
    Dan Clarizio
    @dclarizio
    @chessbyte We used to add nodes to the trees as the user clicked thru, but then as @Fryguy pointed out, after quite a few nodes were open, leaving and revisiting the tree would cause n+1 type fetches to fill in the parts the user had opened prior
    so, @Fryguy optimized that to build the entire tree at the start . . . which has the consequences of taking a long time in super large environments . . . so kind of a catch 22
    Keenan Brock
    @kbrock
    but those trees are only 3 levels deep?
    Dan Clarizio
    @dclarizio
    @kbrock, the second and third accordion trees, yes
    those should also build quickly as we don't populate the VMs in the actual trees
    Oleg Barenboim
    @chessbyte
    @dclarizio thanks for the explanation
    Keenan Brock
    @kbrock
    thanks
    Dan Clarizio
    @dclarizio
    so moving to REST will just move the problem . . . what I'd REALLY like to do is not put the VMs in the tree, just show them on the right, but that would take buy in from PM as it would no longer look like the provider we originally tried to mimic
    Keenan Brock
    @kbrock

    found this:

    records = sliced.map { |slice| records_for(slice) }.flatten
    # vs flat_map

    but it is in rails - no need to patch old rails at this time

    Keenan Brock
    @kbrock
    wow - in VMs, default_value_for shows up all over the place
    can we just put those types of values into a before_validation XX, :on => :create?
    Jason Frey
    @Fryguy
    :point_up: February 3, 2016 2:23 PM we preload the whole tree for performance...try clicking and opening like folders and the refresh the page, and you'll be happy with the preloading :)
    that's what I was trying to explain yesterday :/
    Keenan Brock
    @kbrock
    12% of our render time is forming json
    Jason Frey
    @Fryguy
    the other option is to go back to the old way of tree walking, but somehow do it efficiently
    I couldn't figure out how to make that spaghetti efficient :(
    so 88% is not forming JSON
    Keenan Brock
    @kbrock
    well, can we make a change like that to 5.4?
    Jason Frey
    @Fryguy
    probably not :D
    Keenan Brock
    @kbrock
    well, 79% is from building the left hand tree that becomes the json?
    @matthewd I have a config/initializer with this:
    module ActiveRecord
      module Core
        module ClassMethods
          def inspect
            self.name # super
          end
        end
      end
    end
    Jason Frey
    @Fryguy
    :point_up: February 3, 2016 4:26 PM The whole pint of default_value_for is that it fills in the values properly on .new, .create, and .find ... All of the other methods don't do that
    Keenan Brock
    @kbrock
    it isn't fixing the names. other ideas?
    we need for find?
    Jason Frey
    @Fryguy
    well, it doesn't do anything on find, and that is the point
    Keenan Brock
    @kbrock
    it does
    Jason Frey
    @Fryguy
    so nil and false can be stored in the database and it doesn't set a new default
    Keenan Brock
    @kbrock
    but when you instantiate those objects, we take a performance hit
    Jason Frey
    @Fryguy
    Well, it does patch initialize, but it should be a noop on find
    Keenan Brock
    @kbrock
    I thought it did set a new default if the value was nil
    Jason Frey
    @Fryguy
    no, it doesn't
    only on new or create
    Keenan Brock
    @kbrock
    aah
    allows_nil (default: true)
      Sets explicitly passed nil values if option is set to true
    ok, the docs are funky ref - if set to false, then it will change the value on find too
    Jason Frey
    @Fryguy
    we don't ever change the defaults