Skip to content

test: BatchProcessor stress testing #2788

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

cijothomas
Copy link
Member

Trying out one way to test overall throughput in batching scenarios. This could be another unit test?

@cijothomas cijothomas requested a review from a team as a code owner March 11, 2025 20:41
Copy link

codecov bot commented Mar 11, 2025

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 79.7%. Comparing base (52cd0e9) to head (56c62fb).

Files with missing lines Patch % Lines
opentelemetry-sdk/src/logs/export.rs 0.0% 5 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##            main   #2788     +/-   ##
=======================================
- Coverage   79.7%   79.7%   -0.1%     
=======================================
  Files        123     123             
  Lines      23136   23141      +5     
=======================================
- Hits       18448   18447      -1     
- Misses      4688    4694      +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@scottgerring
Copy link
Contributor

This is a cool idea!

I wonder if ....

  • there are similar examples of this sort of thing in other opentelem projects we can be inspired by (probably you already know this! )
  • there's an idiomatic way ™️ of fitting this into rust's testing infrastructure. E.g. could we structure it to be more like a criterion test ("it took X ms to push through Y logs"), or is that total madness because of the granularity?

@cijothomas
Copy link
Member Author

This is a cool idea!

I wonder if ....

  • there are similar examples of this sort of thing in other opentelem projects we can be inspired by (probably you already know this! )
  • there's an idiomatic way ™️ of fitting this into rust's testing infrastructure. E.g. could we structure it to be more like a criterion test ("it took X ms to push through Y logs"), or is that total madness because of the granularity?

Inspired from .NET's open-telemetry/opentelemetry-dotnet#1086 4 years ago!

We do have some tests similar to this in this repo already (metrics focused), and I expect to make a normal-test one for this.

The stress test is to test various additional scenarios, like what happens in network cable is pulled out, what if only single core is available.. what if we run this for a long time etc.

("it took X ms to push through Y logs")

I'll be working a lot on these kind of ideas for next few weeks/months.
(A specific example is: Today, BatchProcessor sequentially calls Exporter.export(). To achieve higher throughput, this may not be sufficient. We have spec discussion about improving this, so the tests here will prove/disprove the needs)

@scottgerring
Copy link
Contributor

The stress test is to test various additional scenarios, like what happens in network cable is pulled out, what if only single core is available.. what if we run this for a long time etc.

Sounds useful!

Thinking out loud, it'd be amazing if we could track this over time somehow. I don't know if we could use e.g. Sonarqube or bencher, or some other SaasY code quality platform to do this automatically. Maybe that ties into a better way to track the micro-benchmarks too. We could be clever and run this once a week, say, and then bisect manually if there are big regressions.

@cijothomas
Copy link
Member Author

The stress test is to test various additional scenarios, like what happens in network cable is pulled out, what if only single core is available.. what if we run this for a long time etc.

Sounds useful!

Thinking out loud, it'd be amazing if we could track this over time somehow. I don't know if we could use e.g. Sonarqube or bencher, or some other SaasY code quality platform to do this automatically. Maybe that ties into a better way to track the micro-benchmarks too. We could be clever and run this once a week, say, and then bisect manually if there are big regressions.

I'll steal from what Collector is doing: https://opentelemetry.io/docs/collector/benchmarks/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants