After several rally scenario testing, we found that 2 seconds for state change notification interval is not so much aggressive.
On the contrary, I want to say, 16s may let the l3 agent squeeze more notification, and 16s may let the MQ a high pressure.
ENV:
0)stable/mitaka with patch: https://review.openstack.org/#/c/364803/
1)2 controller nodes: httpd, keystone, glance-api/registry, nova-api, nova-conductor, neutron-server, rabbitMQ
2)2 DB nodes: mariadb-10.1.12-4.el7
3)2 network nodes: L3 agent, ovs-agent, openvswitch
4)40 compute nodes: ovs-agent, openvswitch, nova-compute
5)All nodes have corresponding 10G NICs for both data and external networking.
After several rally scenario testing, we found that 2 seconds for state change notification interval is not so much aggressive.
On the contrary, I want to say, 16s may let the l3 agent squeeze more notification, and 16s may let the MQ a high pressure.
ENV: /review. openstack. org/#/c/ 364803/ api/registry, nova-api, nova-conductor, neutron-server, rabbitMQ 10.1.12- 4.el7
0)stable/mitaka with patch: https:/
1)2 controller nodes: httpd, keystone, glance-
2)2 DB nodes: mariadb-
3)2 network nodes: L3 agent, ovs-agent, openvswitch
4)40 compute nodes: ovs-agent, openvswitch, nova-compute
5)All nodes have corresponding 10G NICs for both data and external networking.
Here is quick look of one our tests: paste.openstack .org/show/ 575963/ paste.openstack .org/show/ 575964/
Rally input: http://
Rally output: http://
The attachment is the Rally output in HTML format with full test data and results.