diff options
author | Christian Hopps <chopps@gmail.com> | 2021-05-28 21:16:18 +0200 |
---|---|---|
committer | Christian Hopps <chopps@gmail.com> | 2021-06-02 16:05:26 +0200 |
commit | fd396924d6fedf0c68707b314fb216b6b7544bcb (patch) | |
tree | 27abd7dccef7d523be828bcd683eda51d2e2a5fe /eigrpd | |
parent | Merge pull request #8769 from ton31337/fix/time_to_remove (diff) | |
download | frr-fd396924d6fedf0c68707b314fb216b6b7544bcb.tar.xz frr-fd396924d6fedf0c68707b314fb216b6b7544bcb.zip |
northbound: KISS always batch yang config (file read), it's faster
The backoff code assumed that yang operations always completed quickly.
It checked for > 100 YANG modeled commands happening in under 1 second
to enable batching. If 100 yang modeled commands always take longer than
1 second batching is never enabled. This is the exact opposite of what
we want to happen since batching speeds the operations up.
Here are the results for libyang2 code without and with batching.
| action | 1K rts | 2K rts | 1K rts | 2K rts | 20k rts |
| | nobatch | nobatch | batch | batch | batch |
| Add IPv4 | .881 | 1.28 | .703 | 1.04 | 8.16 |
| Add Same IPv4 | 28.7 | 113 | .590 | .860 | 6.09 |
| Rem 1/2 IPv4 | .376 | .442 | .379 | .435 | 1.44 |
| Add Same IPv4 | 28.7 | 113 | .576 | .841 | 6.02 |
| Rem All IPv4 | 17.4 | 71.8 | .559 | .813 | 5.57 |
(IPv6 numbers are basically the same as iPv4, a couple percent slower)
Clearly we need this. Please note the growth (1K to 2K) w/o batching is
non-linear and 100 times slower than batched.
Notes on code: The use of the new `nb_cli_apply_changes_clear_pending`
is to commit any pending changes (including the current one). This is
done when the code would not correctly handle a single diff that
included the current changes with possible following changes. For
example, a "no" command followed by a new value to replace it would be
merged into a change, and the code would not deal well with that. A good
example of this is BGP neighbor peer-group changing. The other use is
after entering a router level (e.g., "router bgp") where the follow-on
command handlers expect that router object to now exists. The code
eventually needs to be cleaned up to not fail in these cases, but that
is for future NB cleanup.
Signed-off-by: Christian Hopps <chopps@labn.net>
Diffstat (limited to 'eigrpd')
-rw-r--r-- | eigrpd/eigrp_cli.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/eigrpd/eigrp_cli.c b/eigrpd/eigrp_cli.c index cf3999b45..3a978cae3 100644 --- a/eigrpd/eigrp_cli.c +++ b/eigrpd/eigrp_cli.c @@ -79,7 +79,7 @@ DEFPY_YANG( as_str, vrf ? vrf : VRF_DEFAULT_NAME); nb_cli_enqueue_change(vty, xpath, NB_OP_DESTROY, NULL); - return nb_cli_apply_changes(vty, NULL); + return nb_cli_apply_changes_clear_pending(vty, NULL); } void eigrp_cli_show_header(struct vty *vty, struct lyd_node *dnode, |