-
Notifications
You must be signed in to change notification settings - Fork 19
perf(profiling): cache TLS in ProfileExporter::new #1619
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
Merged
gh-worker-dd-mergequeue-cf854d
merged 1 commit into
main
from
PROF-13824-ProfileExporter-new-creates-TLS-config-every-time
Feb 27, 2026
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,82 @@ | ||
| // Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/ | ||
| // SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| //! Pre-initialized TLS configuration for high-performance profile export. | ||
| //! | ||
| //! On Linux, [`TlsConfig::new`] eagerly loads native root certificates via the | ||
| //! platform verifier, avoiding repeated expensive disk I/O on every | ||
| //! [`ProfileExporter`] creation. | ||
| //! | ||
| //! On macOS, the platform verifier's `Verifier::new()` is cheap (no cert | ||
| //! loading), but the actual Security.framework work happens lazily during each | ||
| //! TLS handshake. Creating a [`TlsConfig`] still avoids redundant `reqwest` | ||
| //! client setup on every exporter creation. | ||
| //! | ||
| //! # Fork Safety | ||
| //! | ||
| //! `TlsConfig` does **not** call Security.framework APIs directly, so it is | ||
| //! safe to create before `fork()`. Security.framework work is deferred to | ||
| //! each child's first TLS handshake. | ||
| //! | ||
| //! [`ProfileExporter`]: super::ProfileExporter | ||
|
|
||
| /// Wraps a [`rustls::ClientConfig`] that has been pre-configured with the | ||
| /// platform certificate verifier. Clone is cheap (inner `Arc`). | ||
| #[derive(Clone)] | ||
| pub(crate) struct TlsConfig(pub(crate) rustls::ClientConfig); | ||
|
|
||
| impl TlsConfig { | ||
| /// Create a new TLS configuration using the platform certificate verifier. | ||
| /// | ||
| /// On Linux, this eagerly loads the native root certificate store, which is | ||
| /// the expensive operation that was previously repeated on every | ||
| /// `ProfileExporter::new` call. | ||
| /// | ||
| /// On macOS, this is lightweight; the platform verifier defers | ||
| /// Security.framework calls to the first TLS handshake. | ||
| pub fn new() -> Result<Self, rustls::Error> { | ||
| use rustls_platform_verifier::BuilderVerifierExt; | ||
|
|
||
| // Use an explicit CryptoProvider rather than relying on | ||
| // `CryptoProvider::get_default_or_install_from_crate_features()`. | ||
| // Feature unification can enable both `aws-lc-rs` and `ring` in the | ||
| // same build (reqwest enables aws-lc-rs while libdd-common enables | ||
| // ring on Windows), which causes the automatic detection to panic. | ||
| let provider = rustls::crypto::CryptoProvider::get_default() | ||
| .cloned() | ||
| .unwrap_or_else(|| std::sync::Arc::new(Self::default_crypto_provider())); | ||
|
|
||
| let config = rustls::ClientConfig::builder_with_provider(provider) | ||
| .with_safe_default_protocol_versions()? | ||
| .with_platform_verifier()? | ||
| .with_no_client_auth(); | ||
| Ok(Self(config)) | ||
| } | ||
|
|
||
| /// Returns the platform-appropriate default crypto provider. | ||
| /// | ||
| /// Matches the convention used by `libdd-common`: `aws-lc-rs` on Unix, | ||
| /// `ring` on Windows (where `aws-lc-rs` has issues). | ||
| fn default_crypto_provider() -> rustls::crypto::CryptoProvider { | ||
| #[cfg(unix)] | ||
| { | ||
| rustls::crypto::aws_lc_rs::default_provider() | ||
| } | ||
| #[cfg(not(unix))] | ||
| { | ||
| rustls::crypto::ring::default_provider() | ||
| } | ||
| } | ||
| } | ||
|
|
||
| static TLS_CONFIG: std::sync::LazyLock<Result<TlsConfig, String>> = | ||
| std::sync::LazyLock::new(|| { | ||
| TlsConfig::new().map_err(|err| format!("failed to initialize TLS configuration: {err}")) | ||
| }); | ||
|
|
||
| pub(crate) fn cached_tls_config() -> anyhow::Result<TlsConfig> { | ||
| TLS_CONFIG | ||
| .as_ref() | ||
| .map(Clone::clone) | ||
| .map_err(|err| anyhow::anyhow!("{err}")) | ||
| } |
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tls should not be needed for http / uds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The design of the reqwest library is that a client can connect to multiple URLs. It doesn't know if it will use HTTP/HTTPS until later, but the config is done here.. We can possibly-rewrite the necessary components because we should know if we'll be using HTTPS or not, but that's not how the prior nor current code was designed (probably because we inherit such design unintentionally from tokio/reqwest).