-
-
Notifications
You must be signed in to change notification settings - Fork 209
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 regression v0.2.13 #320
Comments
If you're creating and throwing away reqwest clients #316 could have impacted that by searching for trust stores every time but I wouldn't think that would take a significant amount of time. |
Hello, Thank you for your answer !!! I don't know if you can do something to improve that if not I will close this issue. EDIT: Some data about our benchmarks (cargo bench release mode): Thank you!! |
We can shift this lookup into a |
Hello,
OS: Debian 12 & Ubuntu 24.04
Cargo: 1.81.0
We noticed something really weird in a app we are developing in my team.
The app we are developing is a simple backend that provide a HTTP interface (actix) and do some mongodb request to query data.
We do have some benchmark to monitor the time to process different kind of query. Benchmark consists mainly on doing a lot of http request with the library reqwest (that depends on native-tls)
We noticed on a renovate PR (cargo update deps) that some benchmarks were diverging by a factor 2.
We did reproduce the factor 2 locally between the develop branch and the PR branch.
After some analysis we found out that using our develop branch (native-tls 0.2.12) then updating only native-tls with this command:
cargo update --package native-tls --precise 0.2.13
results in the benchmark degradation of a factor 2.We did check the cargo.lock and the only deps that depends on native-tls is reqwest.
Is it really possible that our issue is due to native-tls ?
Thank a lot
The text was updated successfully, but these errors were encountered: