[openstack-dev] [neutron] Neutron scaling datapoints?

Kevin Benton blak111 at gmail.com
Sun Apr 12 02:17:29 UTC 2015

So IIUC tooz would be handling the liveness detection for the agents. That
would be nice to get ride of that logic in Neutron and just register
callbacks for rescheduling the dead.

Where does it store that state, does it persist timestamps to the DB like
Neutron does? If so, how would that scale better? If not, who does a given
node ask to know if an agent is online or offline when making a scheduling

However, before (what I assume is) the large code change to implement tooz,
I would like to quantify that the heartbeats are actually a bottleneck.
When I was doing some profiling of them on the master branch a few months
ago, processing a heartbeat took an order of magnitude less time (<50ms)
than the 'sync routers' task of the l3 agent (~300ms). A few query
optimizations might buy us a lot more headroom before we have to fall back
to large refactors.
Kevin Benton wrote:

> One of the most common is the heartbeat from each agent. However, I
> don't think we can't eliminate them because they are used to determine
> if the agents are still alive for scheduling purposes. Did you have
> something else in mind to determine if an agent is alive?

Put each agent in a tooz[1] group; have each agent periodically
heartbeat[2], have whoever needs to schedule read the active members of
that group (or use [3] to get notified via a callback), profit...

Pick from your favorite (supporting) driver at:


[1] http://docs.openstack.org/developer/tooz/compatibility.html#grouping
[2] https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315
[3] http://docs.openstack.org/developer/tooz/tutorial/group_

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150411/7cffea1e/attachment.html>

More information about the OpenStack-dev mailing list