Suspected performance regression for RBD back end linked to location sorting
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Fix Released
|
Undecided
|
Abhishek Kekane |
Bug Description
Hi,
For the past few releases (Caracal, Bobcat, maybe earlier) we have noticed that listing images is particularly slow. I've finally had some time to dig into this, and I believe I've tracked it to https:/
We're running the RBD back end primarily, but also have HTTP and Cinder listed in 'enabled_backends', meaning that sort_image_
In our case, images are unlikely to be held in more than one back end at a time, and I noted that adding a length check to the locations list in https:/
Whilst a length check is a workaround, does the sorting operation actually require connections to be opened to the RBD back end? If they are required, could the connections at least be re-used to avoid this time penalty growing linearly with the number of images held by Glance?
Thanks
Changed in glance: | |
status: | New → Triaged |
Changed in glance: | |
assignee: | nobody → Abhishek Kekane (abhishek-kekane) |
May be this needs enhancement at glance store side, at this moment weight is attribute of store instance which we try to fetch at runtime, which also checks if connection is there or not. I think that needs to be avoided at list call.