New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Hubble memory usage and performance on decoding events #17482
Conversation
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall although I have one little suggestion, see below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Just a minor comment to a change that seemed a bit odd to me :)
Found using staticcheck. Signed-off-by: Tobias Klauser <tobias@cilium.io>
To avoid regressions in successive changes. Signed-off-by: Tobias Klauser <tobias@cilium.io>
len is defined for all slices, even nil slices. These have a length of 0, so these checks are not necessary. Signed-off-by: Tobias Klauser <tobias@cilium.io>
Preallocate maps with known size and call json.Unmarshal directly, no need to allocate a json.Decoder. Suggested-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tobias@cilium.io>
95f3f20
to
a2194ca
Compare
Found using prealloc. Signed-off-by: Tobias Klauser <tobias@cilium.io>
These are unused since commit b88afa2 ("monitor: new listener v1.2 with reusing en/decoder"). Signed-off-by: Tobias Klauser <tobias@cilium.io>
To avoid regressions in successive changes to DecodeTraceNotify. Signed-off-by: Tobias Klauser <tobias@cilium.io>
Use byteorder.Native.Uint16 to read the version uint16 directly instead of allocating a bytes.Reader. For L34Decode in hubble this improves performance and memory for each decoded TraceNotify event as follows: name old time/op new time/op delta L34Decode-8 4.30µs ± 7% 4.00µs ± 5% -6.96% (p=0.000 n=10+10) name old alloc/op new alloc/op delta L34Decode-8 1.24kB ± 0% 1.19kB ± 0% -3.87% (p=0.000 n=10+10) name old allocs/op new allocs/op delta L34Decode-8 26.0 ± 0% 23.0 ± 0% -11.54% (p=0.000 n=10+10) Signed-off-by: Tobias Klauser <tobias@cilium.io>
This avoids copying the Service protobuf object and improves performance and memory usage: name old time/op new time/op delta L34Decode-8 4.10µs ± 5% 3.63µs ± 8% -11.51% (p=0.000 n=10+10) name old alloc/op new alloc/op delta L34Decode-8 1.24kB ± 0% 1.03kB ± 0% -16.77% (p=0.000 n=10+10) name old allocs/op new allocs/op delta L34Decode-8 26.0 ± 0% 21.0 ± 0% -19.23% (p=0.000 n=10+10) name old time/op new time/op delta L7Decode-8 6.37µs ±11% 5.79µs ± 4% -9.02% (p=0.000 n=10+10) name old alloc/op new alloc/op delta L7Decode-8 1.53kB ± 0% 1.37kB ± 0% -10.47% (p=0.000 n=10+10) name old allocs/op new allocs/op delta L7Decode-8 36.0 ± 0% 34.0 ± 0% -5.56% (p=0.000 n=10+10) Also, the ok bool return is no longer necessary as callers can just check for a nil return value. This simplifies the logic in (*Parser).Decode a bit and avoids allocating an empty object for cases when no service is found. Signed-off-by: Tobias Klauser <tobias@cilium.io>
a2194ca
to
44e5ce3
Compare
/test |
CI is green and reviews were provided by all teams. Marking as ready to merge. |
The first 7 commits are preparatory cleanup and addition/extension of tests to avoid regressions introduced by the successive two commits. These reduce Hubble's memory usage on L3/4 and L7 event decoding as follows:
See the individual commit messages for details.