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

[Performance] Avoid duplication of metric exporters. #2710

Open
marcalff opened this issue Jun 20, 2024 · 1 comment
Open

[Performance] Avoid duplication of metric exporters. #2710

marcalff opened this issue Jun 20, 2024 · 1 comment
Labels
bug Something isn't working issue:blocked Fix blocked, waiting for other fixes as prerequisites Stale triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@marcalff
Copy link
Member

When exporting metrics at different frequencies, the only possible setup according to the current spec is to:

  • define multiple periodic metric readers, with different frequencies
  • define a metric exporter dedicated for each reader

When all the exporters points to the same endpoint, this creates overhead:

  • in memory, with multiple exporters send buffers
  • in CPU, with multiple SSL sessions between the application and the endpoint
  • in network, with multiple separate TCP/IP connections to the endpoint

To fix this, it should be possible to setup the SDK so that multiple metric readers can share a common metric exporter.

The spec however mentions that each reader owns one exporter, preventing sharing.

This performance improvement is blocked by the following spec change:

@marcalff marcalff added the bug Something isn't working label Jun 20, 2024
@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jun 20, 2024
@marcalff marcalff added the issue:blocked Fix blocked, waiting for other fixes as prerequisites label Jun 20, 2024
@marcalff marcalff added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jul 1, 2024
Copy link

github-actions bot commented Sep 2, 2024

This issue was marked as stale due to lack of activity.

@github-actions github-actions bot added the Stale label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working issue:blocked Fix blocked, waiting for other fixes as prerequisites Stale triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

1 participant