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).