Bug 1413218 - /owners/<owner>/info can be slow (1-2 seconds) when large number of systems are registered
Summary: /owners/<owner>/info can be slow (1-2 seconds) when large number of systems a...
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Dashboard
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-13 23:02 UTC by Chris Duryee
Modified: 2019-08-12 15:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-09-04 17:58:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 19505 0 None None None 2017-05-10 10:16:47 UTC

Description Chris Duryee 2017-01-13 23:02:10 UTC
Description of problem:

With candlepin 0.9.54, the following query pops up as taking over 1000msec:

select count(this_.id) as y0_ from cp_consumer this_ inner join cp_consumer_facts f1_ on this_.id=f1_.cp_consumer_id where this_.owner_id=$1 and f1_.mapkey ilike $2 and f1_.element ilike $3

parameters: $1 = '8a98d3fd568e316701568e31cd1d0001', $2 = 'virt.is_guest', $3 = 'true'

This was on a DB with 20K systems in a single org.

It looks like this is happening around https://github.com/candlepin/candlepin/blob/master/server/src/main/java/org/candlepin/model/OwnerInfoCurator.java#L114-L119.

this is called by the katello dashboard which is updated every 5 seconds, so if the query can be improved, it would reduce postgres load and make the dashboard faster.

I don't have a specific hard target for this, but 100msec or less would be great.

Version-Release number of selected component (if applicable): 0.9.54

I added the following index which reduced the time to 33% of the previous time, but it's still > 500 msec:

create index fact_idx_1 on cp_consumer_facts(mapkey) where mapkey ilike 'virt.is_guest';

Comment 4 Barnaby Court 2017-01-17 21:37:11 UTC
Is this a general RFE that the call to get ownerinfo take less than 100 msec?

If the above statement is true, can you provide the sample data & configuration under which the call should take 100 msec so we can work that onto the backlog?

Comment 5 Chris Duryee 2017-01-17 22:41:06 UTC
100-200msec for the /info call would be great.

I can supply a test DB to use.

Comment 8 Tom McKay 2017-01-19 20:17:50 UTC
My suggestion would be to see what information the dashboard is relying on from the call to candlepin. If this is info that we can perhaps store in our database (and keep up to date w/ candlepin events, if needed).

Comment 9 Barnaby Court 2017-01-23 19:07:36 UTC
Based on a quick discussion with Justin, this is only using the Consumer Count and the breakdown of consumer counts by compliance status. As I understand it that information could already be queried from the Katello database instead of asking Candlepin.

Chris, would that be feasible with the other work you are doing?

Comment 10 Chris Duryee 2017-01-23 20:39:07 UTC
Ya, we can swap it over. I'll leave this BZ as needinfo on me until I create a katello redmine.

Comment 11 Barnaby Court 2017-01-31 15:58:14 UTC
I'm moving this to Dashboard as the work to remove the candlepin dependency will be done there.

Comment 13 Tomer Brisker 2017-05-10 10:16:43 UTC
Created redmine issue http://projects.theforeman.org/issues/19505 from this bug

Comment 15 Bryan Kearney 2018-09-04 17:58:04 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.

Note You need to log in before you can comment on or make changes to this bug.