| Summary: | listing of stack events is slow on a big stack | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Jan Provaznik <jprovazn> | ||||
| Component: | openstack-heat | Assignee: | Thomas Hervé <therve> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Amit Ugol <augol> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 10.0 (Newton) | CC: | mburns, rhel-osp-director-maint, sbaker, shardy, srevivo, therve, zbitter | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | aos-scalability-34 | ||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-01-12 15:21:56 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: | |||||
| Attachments: |
|
||||||
|
Description
Jan Provaznik
2016-11-18 09:11:44 UTC
According to https://review.openstack.org/#/c/326229/, this should have been optimized already. It seems we got a regression, I'll try to have a look. I tested with master on tripleo (rather big stack), and it seems fine: $ time openstack stack event list --nested-depth 4 overcloud | wc -l 1120 real 0m3.671s user 0m1.316s sys 0m0.108s Not blazing fast, but good enough it seems. How many events do you have? Some back-of-the-envelope calculations suggest it's probably a little over 9000 events just to create a stack like this (about 7700 resources, but the stack is scaled out in stages). And those are spread over 350+ stacks. However, as you pointed out, the code appears to be doing exactly 3 DB queries regardless of the number of stacks involved. That suggests that if there's a problem it's likely to be in DB optimisation rather than application optimisation. I wonder if we're missing an index we should have? Created attachment 1227353 [details]
stack events (nested depth 2)
So the given list contains 30k events. I don't think there is much we can do to improve it. We probably should have had a default limit, but it's hard to change that for backward compatibility. In the mean time, you should use limits, markers and filters if you need quick responses. You may also want to use stack failure list. |