Bug 1788749

Summary: Neutron List networks API regression
Product: Red Hat OpenStack Reporter: Sai Sindhur Malleni <smalleni>
Component: openstack-neutronAssignee: Rodolfo Alonso <ralonsoh>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Eran Kuris <ekuris>
Severity: high Docs Contact:
Priority: urgent    
Version: 16.0 (Train)CC: amuller, bcafarel, chrisw, lpeer, njohnston, racedoro, sclewis, scohen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-06 13:58:22 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:

Description Sai Sindhur Malleni 2020-01-08 01:59:44 UTC 
Description of problem:
On running a rally scenario that creates a network and then lists all networks for 1000 times at a concurrency of 16, we see that OSP 16 is relatively slow compared to OSP 13 in both ML2/OVS as well as ML2/OVN case.



95% of API response times in seconds for listing networks
OSP13 ML2/OVS  OSP16 ML2/OVS     OSP13 ML2/OVN    OSP 16 ML2/OVN
  2.41	        4.25	          2.63	           4.26
Version-Release number of selected component (if applicable):
OSP 16

How reproducible:
100%

Steps to Reproduce:
1. Compare OSP 13 neutron API performance with OSP 16
2.
3.

Actual results:
OSP 16 os slower than OSP 13

Expected results:
OSP 16 should perform the same if not better than OSP 13

Additional info:
Comment 2 Rodolfo Alonso 2020-01-14 11:49:22 UTC 
Hello Sai:

I've tested the Neutron API manually, executing the listing command using the OpenStack client. I've read both the Neutron API call time and the command time. I've tested both with OSP13 and OSP16, as you'll see in the results table.

To read the Neutron API call time, I've extracted the log information provided by the server. E.g.:
Jan 14 11:28:26 osdev18 neutron-server[30677]: INFO neutron.wsgi [None req-164eb8c4-c283-4132-bfa8-6e158e85d361 demo admin] 192.168.10.20 "GET /v2.0/networks HTTP/1.1" status: 200  len: 637919 time: 0.8879759


In my testing system I have 1000 networks created. Just to check if there is a significant change in the OpenStack client affecting the object collection and the API call, I've tested with both versions too.

The command used is:
  $ time openstack network list | wc  # To avoid printing in the screen the whole list.

Those are the results:
	N 16	Osclient 16		N 13	Osclient 16
	0.952	3.058			0.93	2.954
	0.964	3.078			0.906	2.956
	1.026	3.168			1.007	2.974
	0.941	3.061			0.96	2.985
	0.982	3.102			0.887	2.897
AVG	0.973	3.0934		AVG	0.938	2.9532
						
	N 16	Osclient 13		N 13	Osclient 13
	0.9353	3.087			0.887	2.952
	0.992	3.121			0.976	2.974
	1.03	3.13			0.93	2.944
	0.96	3.116			0.973	2.945
	0.949	3.077			0.985	3.007
AVG	0.97326	3.1062		AVG	0.9502	2.9644


As you can see:
- The OSclient version does not affect to the Neutron API call.
- The Neutron API call time goes from 0.95 seconds to 0.97 seconds. This performance lost is not significant.

Reviewing the code between OSP13 and OSP16:
- There are no new resource extensions added to "network" object. This usually slows down the object retrieval when creating the output dictionary. But this is not the case here.
- There is only one single modification in the network object/DB register: a new parameter, MTU, was added. This can justify the small increase of time in the API call. Not further processing of this new parameter is done during the object collection.

With those figures I can confirm that there is no regression in the Neutron API for the network listing call.

Regards.
Comment 6 Red Hat Bugzilla 2023-09-14 05:49:31 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days