Bug 1393611

Summary: hammer erratum list command taking too much time to display erratum
Product: Red Hat Satellite Reporter: Nagoor Shaik <nshaik>
Component: HammerAssignee: Tomas Strachota <tstrachota>
Status: CLOSED ERRATA QA Contact: jcallaha
Severity: high Docs Contact:
Priority: high    
Version: 6.2.3CC: bbuckingham, bkearney, dhlavacd, jcallaha, ktordeur, mhulan, mlele, nshaik, oshtaier, tstrachota, zhunting
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rubygem-hammer_cli-0.5.1.13-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1394365 (view as bug list) Environment:
Last Closed: 2017-03-06 08:34:19 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:
Bug Depends On: 1023127, 1418412    
Bug Blocks: 1394365    

Description Nagoor Shaik 2016-11-10 00:53:57 UTC
Description of problem:
hammer erratum list command taking too much time to display erratum, if there are 10+ repositories synchronized into Satellite 

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

How reproducible:
100%

Steps to Reproduce:
1. Synchronize 10 + Server RPMs and other repositories of different RHEL releases
2. Execute hammer erratum list which seems to be hung for a very long time and response/result is taking more than an hour to display i.e. time varies based upon the number of repositories it has to query.

Actual results:
With 10+ repositories time took to display the result was around 

real    69m32.042s
user    66m39.418s
sys     0m1.193s

Expected results:
Should display the result immediately as REST API of the same does.

Additional info:

If we query the same information through REST API, the results are pretty fast.

Comment 3 Tomas Strachota 2016-11-23 15:00:15 UTC
Nagoor,
could you please attach full output of hammer -d erratum list from the machine where you experienced the slowness? Thank you!

Comment 4 Mihir Lele 2016-12-04 11:19:38 UTC
Hello Tomas,

I have taken over this case from Nagoor.

I am attaching the full output of "# hammer -d erratum list --content-view "AMAT Certified RHEL 6 FY2017Q1 64-bit"" which was provided by the customer.

If you need anything else, let me know.

Regards,
Mihir

Comment 5 Mihir Lele 2016-12-04 11:20:20 UTC
Hello Tomas,

I have taken over this case from Nagoor.

I am attaching the full output of "# hammer -d erratum list --content-view "AMAT Certified RHEL 6 FY2017Q1 64-bit"" which was provided by the customer.

If you need anything else, let me know.

Regards,
Mihir

Comment 7 Tomas Strachota 2016-12-16 11:29:25 UTC
Thank you very much from the logs, Mihir. 

From the timestamps in the log it seems the complete data was fetched in 3 minutes and the rest of the time was hammer trying to print it:
- started:       2016-11-30 22:50:24
- last response: 2016-11-30 22:53:29
- time - real:              02:18:58
------------------------------------
- getting data took:        00:03:05
- print time:               02:15:53

It seems that printing tables is terribly suboptimal.

Comment 13 Bryan Kearney 2016-12-19 17:12:11 UTC
Upstream bug assigned to tstrachota

Comment 14 Bryan Kearney 2016-12-19 17:12:15 UTC
Upstream bug assigned to tstrachota

Comment 15 Bryan Kearney 2016-12-21 17:11:38 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17740 has been resolved.

Comment 18 jcallaha 2017-02-21 15:47:07 UTC
Verified in Satellite 6.2.8 Snap 3

While there are no standards for errata count, the results below look like a significant improvement over the previous performance.

Satellite with 6,335 errata:
real	1m35.424s
user	0m11.889s
sys	0m0.714s

Satellite with 33,289 errata:
real	5m28.468s
user	0m39.740s
sys	0m1.505s

Comment 20 errata-xmlrpc 2017-03-06 08:34:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0447