Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Dashboard
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-13 23:02 UTC by Chris Duryee
Modified: 2021-09-09 12:04 UTC (History)
7 users (show)

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

Attachments (Terms of Use)


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