Bug 1413218

Summary:	/owners/<owner>/info can be slow (1-2 seconds) when large number of systems are registered
Product:	Red Hat Satellite	Reporter:	Chris Duryee <cduryee>
Component:	Dashboard	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.2.6	CC:	bcourt, bkearney, cduryee, crog, jcallaha, tbrisker, tomckay
Target Milestone:	Unspecified	Keywords:	Performance, Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-09-04 17:58:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.