The lookup benchmark was incorrect. When looking up a large number of
prefixes on each loop, b.Loop() calibrate on a larger and less precise
value than if it were measuring only one lookup where it would iterate
more to get a precise timing.
The problem may also exist for the insertion benchmark, but it's
difficult to do only one insertion per loop, as after many iterations,
there is nothing more we can insert. I suppose BART's author is not
trying to benchmark insertions because of this.
See https://github.com/akvorado/akvorado/pull/2040 and
https://github.com/gaissmai/bart/issues/351#issuecomment-3428806758.
Some of the files were quite big:
- asns.csv ~ 3 MB
- index.js ~ 1.5 MB
- *.svg ~ 2 MB
Use a ZIP archive to put them all and embed it. This reduce the binary
size from 89 MB to 82 MB. 🤯
This also pulls some code modernization (use of http.ServeFileFS).
Now:
```
goos: linux
goarch: amd64
pkg: akvorado/orchestrator/geoip
cpu: AMD Ryzen 7 PRO 6850U with Radeon Graphics
BenchmarkIterDatabase/ASN-16 3376 457.0 ns/entry
BenchmarkIterDatabase/GeoIP-16 2410 754.5 ns/entry
```
Before 0a10764cc9:
```
goos: linux
goarch: amd64
pkg: akvorado/orchestrator/geoip
cpu: AMD Ryzen 7 PRO 6850U with Radeon Graphics
BenchmarkIterDatabase/ASN-16 2863 609.3 ns/entry
BenchmarkIterDatabase/GeoIP-16 3286 719.3 ns/entry
```
I was hoping for a bit more!
I did not benchmark it myself, but it was benchmarked here:
https://github.com/osrg/gobgp/issues/1414#issuecomment-3067255941
Of course, no guarantee that this benchmark matches our use cases.
Moreover, SubnetMap have been optimized to avoid parsing keys all
the time.
Also, the interface is a bit nicer and it uses netip.Prefix directly.
The next step is to convert outlet/routing/provider/bmp.
When using `mapstructure:",squash"`, most structure-specific hook don't
dive into the structure as they are provided with the parent structure.
Add an helper to make them work on the embedded structure as well and
use it for the generic "deprecated fields" hook, but also for the hook
for the common Kafka configuration.
This is a bit brittle. There are other use cases, but they may not need
this change.
The concurrency of this library is easier to handle than Sarama.
Notably, it is more compatible with the new model of "almost share
nothing" we use for the inlet and the outlet. The lock for workers in
outlet is removed. We can now use sync.Pool to allocate slice of bytes
in inlet.
It may also be more performant.
In the future, we may want to commit only when pushing data to
ClickHouse. However, this does not seem easy when there is a rebalance.
In case of rebalance, we need to do something when a partition is
revoked to avoid duplicating data. For example, we could flush the
current batch to ClickHouse. Have a look at the
`example/mark_offsets/main.go` file in franz-go repository for a
possible approach. In the meantime, we rely on autocommit.
Another contender could be https://github.com/segmentio/kafka-go. Also
see https://github.com/twmb/franz-go/pull/1064.
This change split the inlet component into a simpler inlet and a new
outlet component. The new inlet component receive flows and put them in
Kafka, unparsed. The outlet component takes them from Kafka and resume
the processing from here (flow parsing, enrichment) and puts them in
ClickHouse.
The main goal is to ensure the inlet does a minimal work to not be late
when processing packets (and restart faster). It also brings some
simplification as the number of knobs to tune everything is reduced: for
inlet, we only need to tune the queue size for UDP, the number of
workers and a few Kafka parameters; for outlet, we need to tune a few
Kafka parameters, the number of workers and a few ClickHouse parameters.
The outlet component features a simple Kafka input component. The core
component becomes just a callback function. There is also a new
ClickHouse component to push data to ClickHouse using the low-level
ch-go library with batch inserts.
This processing has an impact on the internal representation of a
FlowMessage. Previously, it was tailored to dynamically build the
protobuf message to be put in Kafka. Now, it builds the batch request to
be sent to ClickHouse. This makes the FlowMessage structure hides the
content of the next batch request and therefore, it should be reused.
This also changes the way we decode flows as they don't output
FlowMessage anymore, they reuse one that is provided to each worker.
The ClickHouse tables are slightly updated. Instead of using Kafka
engine, the Null engine is used instead.
Fix#1122
Instead, just map configuration files inside the container. As we don't
have to push the schema anymore, pushing some arbitrary configuration
does not seem to be our job.
