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

feat(s2n-quic-dc): emit cleaner events #2392

Merged
merged 3 commits into from
Dec 2, 2024
Merged

Conversation

camshaft
Copy link
Contributor

@camshaft camshaft commented Dec 2, 2024

Description of changes:

This change adds an event for the s2n_quic_dc::path::secret::map::Cleaner background thread. This allows a subscriber to get insight into how often the cleaner thread is running and what kind of work is being done. It also emits map utilization metrics.

Call-outs:

I renamed the len method in the fixed_map module to be count, since it iterates over all of the slots and sums up the len.

The stable clippy task is failing due to a new version being released over the weekend. That will be fixed in another PR.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@camshaft camshaft marked this pull request as ready for review December 2, 2024 18:53

/// The utilization percentage of the available number of entries before the cycle
#[measure("utilization.initial", Percent)]
initial_utilization: f32,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we missing a utilization for the addresses (or the IDs)? I wonder if we should have a consistent prefix/suffix to make it clearer that you're not looking at an aggregate and need to inspect both metrics and not just one of them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is from the IDs. But I can change it to emit for both with the prefixes.

60
} else {
rand::thread_rng().gen_range(5..60)
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're sort of not deterministic anyway since this is wall clock time... but I guess this seems fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For sure. But this is at least better than what we had before 😄. The snapshots were quite flaky.

let map = Map::new(signer, capacity, NoopClock, sub);

// sleep so the cleaner has time to emit events
std::thread::sleep(core::time::Duration::from_millis(100));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we run the cleaner.clean() on the primary thread at Drop time or similar?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're saying just to get the events?

@camshaft camshaft force-pushed the camshaft/dc-utilization-events branch from ca54f60 to 427b901 Compare December 2, 2024 20:29
retired_entries: usize,

/// The utilization percentage of the available number of entries after the cycle
#[measure("entries.utilization", Percent)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this still feels like a metric that at first glance describes aggregate utilization, rather than of a single map of many. Maybe we can name both kinds something like entries.ids.utilization and entries.addresses.utilization? That makes it much clearer IMO that someone looking at that metric should expect other stuff in the entries. category for other kinds of entries.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense. i can change it

@camshaft camshaft merged commit 3743cdf into main Dec 2, 2024
82 of 84 checks passed
@camshaft camshaft deleted the camshaft/dc-utilization-events branch December 2, 2024 21:35
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