The underlying issue is the database cannot (at least is not presently) able to perform the filter for us and simply returns all the objects which leaves Ruby with a much larger (everything) set to process. Currently the MIQ_Report code passes / copies the set of objects multiple times during processing which increases memory and cpu utilization. Testing indicates the current (5.5) code filters ~1,000 datastores per second on an essentailly idle appliance with no memory constraint, thus page rendering time is approximately (# of objects / 1,000) per second best case. The following filters are not performed within the database, thus can be expected to experience slowness at scale: - % Free Space - Total Provisioned Space - Total Hosts - Managed/Registered VMs - Managed/Unregistered Vms - Unmanaged VMs
Closing this 5.5.2 instance of this ticket as amy additional changes to improve the performance of the non-DB filtered options will require major changes to how we implement filtering. Unless there is memory contention on the appliance I do not expect the filtering performance to be a significant issue for customers. I'm leaving the original (https://bugzilla.redhat.com/show_bug.cgi?id=1182777) ticket open for 5.6 as we evaluate changing the filtering model (leverage more filtering in the DB).