Difference between revisions of "Nicira-plugin-get-improvements"
(→Detailed Description) |
|||
| Line 8: | Line 8: | ||
It's therefore advisable to move operational state synchronization to a distinct task, which can be repeated at a periodic interval. | It's therefore advisable to move operational state synchronization to a distinct task, which can be repeated at a periodic interval. | ||
| − | This task will synchronize the status for all the relevant resources (networks, ports, and routers). This can be achieved with a very limited number of queries to NVP | + | This task will synchronize the status for all the relevant resources (networks, ports, and routers). This can be achieved with a very limited number of queries to NVP. |
| − | The number of queries | + | The number of queries will increase slowly with the number of resources managed by Quantum (3 * num_resources div 1000); however the response size will increase. |
== API Changes == | == API Changes == | ||
| Line 35: | Line 35: | ||
At each execution of such periodic task the following queries will be executed on the NVP backend: | At each execution of such periodic task the following queries will be executed on the NVP backend: | ||
| − | /ws.v1/lswitch/*/lport? | + | /ws.v1/lswitch/*/lport?fields=uuid,tags,link_status_up,admin_status_up,fabric_status_up&relations=LogicalPortStatus |
| − | /ws.v1/lrouter? | + | /ws.v1/lrouter?fields=uuid%2Ctags%2Cfabric_status%2C%20&relations=LogicalRouterStatus |
| + | /ws.v1/lswitch?fields=uuid%2Ctags%2Cfabric_status%2C%20&relations=LogicalSwitchStatus | ||
Field selection will reduce response size. | Field selection will reduce response size. | ||
| − | By default NVP responses are paginated. This means | + | By default NVP responses are paginated, with a maximum page size of 5,000 (default 1,000). This means that several queries might be needed to fetch the status for all entities. |
| + | In order to improve processing of responses with multiple pages, the result of a query can be processed while the subsequent query is being executed. | ||
| + | |||
| + | during synchronization we won't block access to the Quantum database. | ||
| + | Update queries will be performed only for those items whose status has changed. | ||
== Open items == | == Open items == | ||
| + | |||
| + | * Bring maximum page size to 5,000 items | ||
| + | * Investigate whether synchronization of logical switches can be done without querying NVP (status inferred by ports on switches) | ||
| + | * Provide a shortcut for explicting fetching the status for a resource (e.g.: explicitly adding 'status' to the list of fields) | ||
Revision as of 22:00, 18 June 2013
Contents
Improving performance of GET operations in the Nicira Plugin
High level description
Currently the Nicira plugin synchronizes the operational status for most resource at each GET request, to the aim of returning always an up-to-date information of the operational status of a resource. This however becomes a performance bottleneck especially when the REST/RPC traffic increases, as the NVP backend is hit for each GET request. Some operations, such as those from DHCP agent, tend to execute a get operation for every object they need to synchronize, thus leading to linearly increasing accesses to the NVP backend.
It's therefore advisable to move operational state synchronization to a distinct task, which can be repeated at a periodic interval. This task will synchronize the status for all the relevant resources (networks, ports, and routers). This can be achieved with a very limited number of queries to NVP. The number of queries will increase slowly with the number of resources managed by Quantum (3 * num_resources div 1000); however the response size will increase.
API Changes
No API change will be performed as part of this blueprint
Data Model Changes
No data model change.
Detailed Description
The following operations mapped to GET API operations will stop fetching entities from NVP to gather their operational status
* get_network * get_networks * get_router * get_routers * get_port * get_ports
The operational status will always be returned from the value stored in the database. Such value will be updated periodically (to this aim oslo-incubator PeriodicTask might be used). Deployers should be able to tune the frequency of this periodic task using a configuration variable.
At each execution of such periodic task the following queries will be executed on the NVP backend:
/ws.v1/lswitch/*/lport?fields=uuid,tags,link_status_up,admin_status_up,fabric_status_up&relations=LogicalPortStatus /ws.v1/lrouter?fields=uuid%2Ctags%2Cfabric_status%2C%20&relations=LogicalRouterStatus /ws.v1/lswitch?fields=uuid%2Ctags%2Cfabric_status%2C%20&relations=LogicalSwitchStatus
Field selection will reduce response size. By default NVP responses are paginated, with a maximum page size of 5,000 (default 1,000). This means that several queries might be needed to fetch the status for all entities. In order to improve processing of responses with multiple pages, the result of a query can be processed while the subsequent query is being executed.
during synchronization we won't block access to the Quantum database. Update queries will be performed only for those items whose status has changed.
Open items
- Bring maximum page size to 5,000 items
- Investigate whether synchronization of logical switches can be done without querying NVP (status inferred by ports on switches)
- Provide a shortcut for explicting fetching the status for a resource (e.g.: explicitly adding 'status' to the list of fields)
