Comment 4 for bug 2037107

Hello:

I'm using master branch to reproduce this issue, I don't have a Yoga environment. I can't reproduce the issue using the steps provided. I've created up to 2000 RBAC registers and the time spent to create a FIP in the public network is around 5 seconds:
INFO neutron.wsgi [None req-685f2007-eecf-462c-972a-fd1ff52e604a None admin] 192.168.10.100 "POST /networking/v2.0/floatingips HTTP/1.1" status: 201 len: 753 time: 5.1634228

Considering that I'm running standalone devstack deployment in a virtual machine, this time is a content time.

Replying to some questions referred in previous comments:
1) The change of the RBAC registers loading strategy.
As commented in the commit message of [1], this is increasing the complexity of the resource queries because is joining the RBAC registers query to the resource query. Here we need to differentiate two situations:
a) When the query is performed by an admin, the query performed will retrieve the RBAC registers just matching the resource ID (check [3])
b) When the query is performed by a non-admin user, the query will be improved by [4]: the RBAC complex filter query will have a very low cardinality when the number of RBAC registers is high. However, the n-lib group-by clause will reduce the returned query to just the number of resources (number of subnets in your case).

2) The group-by clause won't help in the admin case.
That is replied in the previous question. It is not needed because in the admin case we don't filter the RBAC registers by action or target project. The admin has all permissions and we don't need to filter them (check [3]).

3) Change the network subnet load method to lazy="selectin".
Please check [5] to understand the rationale of this change. When the network is retrieved, the subnets are not by default. That is OK in most of the cases where we don't need the subnet values. If you change the load method, we'll be retrieving the subnet information any time we retrieve a network, reducing the API performance for some network get calls.

4) Change the RBAC filtering.
"Things like [3] are not really performant and should be handeled by mysql." Sorry, I don't understand this statement. We have already improved the RBAC retrieval; at this point the network resource has the RBAC registers stored in the OVO. This check, regardless of the number of RBAC registers, will be very fast.

To confirm that this is not a problem in your deployment, please enable the MySQL slow query register and report any query above 1-2 seconds. I've enabled that in my env and I don't see any. Please check the MySQL version you are running and the SQLAlchemy version installed.

Regards.

[1]https://review.opendev.org/c/openstack/neutron/+/884877
[2]https://github.com/openstack/neutron-lib/blob/bdebe1de3c9e4032a7a40785846065b676b45b64/neutron_lib/db/model_query.py#L123
[3]https://paste.opendev.org/show/bSPFHtntEymdGOzBAQzU/
[4]https://review.opendev.org/q/topic:bug%252F1918145
[5]https://review.opendev.org/c/openstack/neutron/+/409901
[6]https://opendev.org/openstack/neutron/src/commit/8e38e57b8000ca6ce9ab84692a9aba6220556a3d/neutron/db/db_base_plugin_common.py#L348-L356