do not filter endpoints by procspied/ebpf in renderers #2652
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The filtering of endpoints causes some connections to get missed for non-eBPF-tracked connections. Furthermore, the filtering of endpoints is entirely pointless when the probes run eBPF since the filters just pass through eBPF-tracked endpoints (for good reason too; because otherwise some connections would be missed). So in that case it is just costing CPU and removing it actually improves performance. Note that removing the filtering does not result in over-counting connections since that is done by source ip:port pairs. Fixes #2551. Fixes #2558.
The change is necessitated by the removal of procspied/ebpf endpoint filtering in the renderers, as a result of which the odd conntracked-only, unconnected pseudo node can sneak through. This new way of doing things also makes renderers more composable and robust, and more directly reflects the objective: - in the process topologies, filter out all unconnected nodes - in all other topologies, filter out unconnected pseudo nodes
|
Performance comparison using a recent eBPF-based Weave Cloud prod report, timing the http api calls to retrieve topologies:
(all times in seconds) |
|
More accurate, cleaner code and it even improves performance: fantastic |
2opremio
approved these changes
Jun 28, 2017
2opremio
reviewed
Jun 28, 2017
| @@ -22,7 +22,7 @@ func renderProcesses(rpt report.Report) bool { | |||
| } | |||
|
|
|||
| // EndpointRenderer is a Renderer which produces a renderable endpoint graph. | |||
| var EndpointRenderer = FilterProcspiedOrEBPF(SelectEndpoint) | |||
| var EndpointRenderer = SelectEndpoint | |||
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
For the eBPF case. It hurts performance for the non-eBPF case. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The filtering of endpoints causes some connections to get missed for non-eBPF-tracked connections. Furthermore, the filtering of endpoints is entirely pointless when the probes run eBPF since the filters just pass through eBPF-tracked endpoints (for good reason too; because otherwise some connections would be missed). So in that case it is just costing CPU and removing it actually improves performance.
Note that removing the filtering does not result in over-counting connections since that is done by source ip:port pairs.
Fixes #2551.
Fixes #2558.