The rendering code checks whether endpoint IPs are part of
cluster-local networks. Due to the prevalence of endpoints - medium
sized reports can contain many thousands of endpoints - this is
performance critical. Alas the existing code performs the check via a
linear scan of a list of networks. That is slow when there are more
than a few, which will be the case in the context of k8s, since there
the probes register service IPs as local /32 networks.
Here we change representation of the set of networks to a prefix
tree (aka trie), which is well-suited for IP network membership checks
since networks are in fact a bitstring prefixes.
The specific representation is a crit-bit tree, but that choice was
purely based on implementation convenience - the chosen library is the
only one I could find that directly supports IP networks.
The rendering code checks whether endpoint IPs are part of
cluster-local networks. Due to the prevalence of endpoints - medium
sized reports can contain many thousands of endpoints - this is
performance critical. Alas the existing code performs the check via a
linear scan of a list of networks. That is slow when there are more
than a few. Unfortunately in some common k8s network setups, e.g. on
AWS, a cluster can contain hundreds of networks, due to /32 networks
derived from interfaces with multiple IPs.
Here we change representation of the set of networks to a prefix
tree (aka trie), which is well-suited for IP network membership checks
since networks are in fact a bitstring prefixes.
The specific representation is a crit-bit tree, but that choice was
purely based on implementation convenience - the chosen library is the
only one I could find that directly supports IP networks.
...by removing them. It was a ridiculous amount of contorted code to
test some utterly trivial functionality that is largely provided by
the golang stdlib.
This isn't going to noticeably improve performance, but enables future
optimisations, e.g. more compact representations of LatestMaps where
many/all entries share the same timestamp.
We want the middle ground between a small compression size, a fast
compression time and a fast decompression time.
Tests suggest that the default compression level is better than the
maximum compression level: although the reports are 4% bigger and
decompress slower, they compress 33% faster.
See discussion on https://github.com/weaveworks/scope/issues/1457#issuecomment-293288682
By reducing the number of times we refer to every topology by name line by line,
we make it easier to add new topologies, reduce the risk of bugs where a topology is not listed,
and reduce the risk of the repeated lines getting out of sync with each other.
We introduce two new methods to assist this:
WalkPairedTopologies, a modified WalkTopologies that gives the called function
the same topology from two reports. This is used, for example, to implement Copy and Merge.
TopologyMap, which returns a map of all topologies by name. This is then used to implement all other methods.
This leaves only 4 instances of listing topologies:
In the consts at the top of the file, to give it a name
In the struct itself
In the constructor, where we need to set per-topology settings
In TopologyMap
Structs like StringLatestMap now use ps.Map directly, which saves
a memory allocation for LatestEntry.Value to point to.
The values in the ps.Map are now pointers, which saves a memory
allocation indirecting a value type to an interface{}
This is important for two reasons:
* It prevents nasty false-equality bugs when two different services from different ECS clusters
are present in the same report
* It allows us to retrieve the cluster and service name - all the info we need to look up the service -
using only the node ID. This matters, for example, when trying to handle a control request.
The new probe will convert all node's LatestControls to Controls, so
the old app can consume them. Also, the new app will convert all
node's Controls to LatestControl, so it can consume the reports from
old probes.
