Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
time hammer content-host list --organization <orgname>
Error: Request Timeout
real 2m2.340s
user 0m1.179s
sys 0m0.220s
Version-Release number of selected component (if applicable):
satellite 6.1.4
How reproducible:
unknown
(in this environment here with >500 content hosts the issue always exists)
Steps to Reproduce:
1. register more than 500 content hosts
2. hammer content-host list --organization <orgname>
3.
Actual results:
Error: Request Timeout
Expected results:
<result should be displayed>
Additional info:
- using ":request_timeout: -1", the result appears
- enforcing paging, the result also is displayed. I.e. "hammer content-host list --organization <orgname> --per-page 300". Using "--per-page 500", the timeout is hit again.
- The time for execution suggests that the code contains a bug. From what I understand, this should be a simple database query. Instead it takes a very long time:
--------
[root@sat6 ~]# time hammer content-host list --organization orgname
Error: Request Timeout
real 2m2.340s
user 0m1.179s
sys 0m0.220s
[root@sat6 ~]# time hammer content-host list --organization orgname --per-page 300
...
real 0m49.191s
user 0m5.763s
sys 0m0.240s
[root@sat6 ~]# time hammer content-host list --organization orgname --per-page 400
...
real 1m8.274s
user 0m9.259s
sys 0m0.250s
[root@sat6 ~]# time hammer content-host list --organization orgname --per-page 450
Error: Request Timeout
real 2m1.703s
user 0m1.100s
sys 0m0.105s
[root@sat6 ~]# time hammer content-host list --organization orgname --per-page 500
Error: Request Timeout
real 2m1.365s
user 0m1.040s
sys 0m0.087s
[root@sat6 ~]# time hammer content-host list --organization orgname --search "be*" (this should yield 470 machines)
Error: Request Timeout
real 2m1.184s
user 0m1.021s
sys 0m0.108s
[root@sat6 ~]# time hammer content-host list --organization orgname --search "a*" (this should yield about 25 machines)
...
real 0m4.573s
user 0m1.168s
sys 0m0.137s
--------
Performance improvement can be gained by including the proper tables (N+1 queries) at the beginning, rather than requesting more data from the DB in the view layer:
Before:
2016-08-09T09:28:22 ef4eff65 [app] [I] Completed 200 OK in 30798ms (Views: 28758.6ms | ActiveRecord: 1144.1ms)
2016-08-09T09:30:29 ef4eff65 [app] [I] Completed 200 OK in 29078ms (Views: 27504.6ms | ActiveRecord: 1114.1ms)
2016-08-09T09:31:04 ef4eff65 [app] [I] Completed 200 OK in 29546ms (Views: 27802.8ms | ActiveRecord: 1237.9ms)
Average: 29807.3ms
After:
2016-08-09T09:24:13 ef4eff65 [app] [I] Completed 200 OK in 24099ms (Views: 22732.9ms | ActiveRecord: 705.7ms)
2016-08-09T09:25:48 ef4eff65 [app] [I] Completed 200 OK in 22791ms (Views: 21248.9ms | ActiveRecord: 621.4ms)
2016-08-09T09:26:14 ef4eff65 [app] [I] Completed 200 OK in 21944ms (Views: 20642.8ms | ActiveRecord: 683.7ms)
Average: 22944.6
That's 23% faster.
Verification could be to look for N+1 warnings in the production.log while requesting the hosts page before applying. The warnings should not show up after applying the fix, and you should be able to notice a speed improvement in the response for a Satellite with hundreds of hosts.