Skip to content
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

Merged
merged 9 commits into from Sep 29, 2021

Conversation

tklauser
Copy link
Member

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:

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)

See the individual commit messages for details.

@tklauser tklauser added kind/performance There is a performance impact of this. release-note/minor This PR changes functionality that users may find relevant to operating Cilium. sig/hubble Impacts hubble server or relay labels Sep 28, 2021
@tklauser tklauser requested a review from a team as a code owner September 28, 2021 10:09
@tklauser tklauser requested review from a team, nathanjsweet and jrfastab September 28, 2021 10:09
@tklauser
Copy link
Member Author

/test

@tklauser tklauser changed the title Improve Hubble memory usage on decoding events Improve Hubble memory usage and performance on decoding events Sep 28, 2021
Copy link
Member

@rolinh rolinh left a 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.

pkg/labels/labels.go Outdated Show resolved Hide resolved
Copy link
Contributor

@kkourt kkourt left a 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 :)

pkg/identity/model/identity.go Show resolved Hide resolved
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>
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>
@tklauser
Copy link
Member Author

/test

@tklauser
Copy link
Member Author

CI is green and reviews were provided by all teams. Marking as ready to merge.

@tklauser tklauser added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Sep 29, 2021
@jibi jibi merged commit a87aa57 into cilium:master Sep 29, 2021
@tklauser tklauser deleted the hubble-mem-usage branch September 29, 2021 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/performance There is a performance impact of this. ready-to-merge This PR has passed all tests and received consensus from code owners to merge. release-note/minor This PR changes functionality that users may find relevant to operating Cilium. sig/hubble Impacts hubble server or relay
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants