xapi-project / xen-api / 12300506080
78%
master: 80%

LAST BUILD BRANCH: private/changleli/sync-with-master
DEFAULT BRANCH: master
Ran
Jobs 1
Files 37
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 78.273%. Remained the same
12300506080

push

github

web-flow 
CP-52526: rate limit event updates (#6126)

We generate O(N^2) events when we update O(N) fields: each field update
generates an event including the entire object, even if later we are
going to change other fields of the same object.

Instead of returning the individual field update events immediately (and
generating a storm of events whenever an API client watcher for VM power
events), we batch these event updates by introducing a minimum amount of
time that successive Event.from need to have between them.
(The client is working as expected here: when it gets an event and
processes it, it immediately calls Event.from to get more events)

Although this doesn't guarantee to eliminate the O(N^2) problem, in
practice it reduces the overhead significantly.

There is one case where we do want almost immediately notification of
updates: task completions (because then the client likely wants to send
us more tasks).

This PR makes the already existing rate limiting in Xapi_event
consistent and configurable, but doesn't yet introduce a batching delay
for Event.from (it does for Event.next, which is deprecated). A separate
PR (or config change) can then enable this for testing purposes, but
also allows us to roll the change back by changing the tunable in the
config file.

There is also a new microbenchmark introduced here, I'll need to update
that with the latest results.

3462 of 4423 relevant lines covered (78.27%)

0.78 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 12300506080.1 37
78.27
 GitHub Action Run
Source Files on build 12300506080