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

Add a facility for exposing metrics from the native engine #5808

Merged
merged 10 commits into from
May 14, 2018

Conversation

stuhood
Copy link
Member

@stuhood stuhood commented May 11, 2018

Problem

As described in #5736, some of the metrics we've recently added introduce dependencies on having constructed a BuildGraph. In order to unblock removing the BuildGraph requirement in #4769, we'd like to replace those metrics with forward compatible metrics computed in the native engine.

Solution

Split out a Session type which represents a scope for metrics capture. Currently the Session records the root requests that were made during its lifetime, which allows it to later determine which nodes are reachable from those roots. In future, additional metrics could be captured in the Session object at the beginning (ie, when it is created) or "end" (when session.metrics() is called) of the Session.

The python objects representing the scheduler were renamed to Scheduler and SchedulerSession to represent this split. pantsd reuses a Scheduler for its entire lifetime, but creates a new SchedulerSession per client request, which is then used post fork as well.

Result

The affected_target_file_count metric was replaced with affected_file_count metric, based on the count of digests reachable from all of the roots in a session. Fixes #5736 and unblocks adding further scheduler metrics.

Copy link
Contributor

@illicitonion illicitonion left a comment

Choose a reason for hiding this comment

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

Looks good! Thanks! :)

self.visualize_rule_graph_to_file(os.path.join(self.visualize_to_dir(), rule_graph_name))

# Create the native Scheduler and Session.
# TODO: This `_tasks` reference could be a local variable, since it is not used
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason not to now?

Copy link
Member Author

@stuhood stuhood May 13, 2018

Choose a reason for hiding this comment

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

I was trying not to get sucked into sideprojects, since I generally make PRs that are way too large. But sure, why not!

Oh, but the backstory is that it was already factored this way, and I was just moving things around while avoiding refactoring them.

Copy link
Member Author

Choose a reason for hiding this comment

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

...and actually, I think it might be a non-trivial sideproject. Going to leave it as is for now.

with self.fork_lock:
self._graph_helper.warm_product_graph(spec_roots)
return self._graph_helper
target_roots = target_roots_calculator.create(
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to be inside the lock?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it should be. Wasn't before, but should be.

.into_iter()
.map(|(metric, value)| {
externs::store_tuple(&[
externs::store_bytes(&metric.bytes().collect::<Vec<_>>()),
Copy link
Contributor

Choose a reason for hiding this comment

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

externs::store_bytes(metric.as_bytes()),

@@ -93,6 +117,21 @@ impl Scheduler {
})
}

///
/// TODO: Convert `extern::store_i32` to i64, and expand the range here.
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason not to do this now?

Copy link
Member Author

Choose a reason for hiding this comment

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

This one is easier. Will do here.

@@ -15,6 +16,29 @@ use nodes::{NodeKey, Select};
use rule_graph;
use selectors;

pub struct Session {
// The set of roots that have been requested within this session.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a comment explaining why we're using interior mutability here rather than &mut self on extend?

@@ -15,6 +15,10 @@ def __init__(self):
self.affected_targets_size = 0
self.affected_targets_file_count = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you can xx this now that it is no longer used.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, yep. Thanks.

Copy link
Member Author

Choose a reason for hiding this comment

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

...except I'm expecting green CI. Will nuke it in a followup.

@@ -15,6 +16,29 @@ use nodes::{NodeKey, Select};
use rule_graph;
use selectors;

pub struct Session {
Copy link
Contributor

Choose a reason for hiding this comment

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

How do you feel about adding a doc comment to this? Is it too early?

Copy link
Member Author

Choose a reason for hiding this comment

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

Added.

@stuhood stuhood force-pushed the stuhood/affected-files-in-rust branch from 202ec2b to 07a4e88 Compare May 14, 2018 00:26
@stuhood stuhood merged commit 530a826 into pantsbuild:master May 14, 2018
@stuhood stuhood deleted the stuhood/affected-files-in-rust branch May 14, 2018 02:48
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.

3 participants