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

Improve system profiling tooling #91

Open
jonhoo opened this issue Sep 19, 2018 · 3 comments
Open

Improve system profiling tooling #91

jonhoo opened this issue Sep 19, 2018 · 3 comments
Labels
enhancement New feature or request m-debugging Related to system debuggability perf Performance-oriented issues

Comments

@jonhoo
Copy link
Contributor

jonhoo commented Sep 19, 2018

The system currently outputs very little information that is useful for profiling. Information such as:

  • Time spent in different parts of domain processing.
  • Rate of backfills and record processing.
  • Time between domain wakeups.
  • Number of packets received/processed.
  • Number of domain timeouts handled.

This would be hugely helpful for nailing down performance problems (in addition to #90).

@jonhoo jonhoo added enhancement New feature or request good first issue Good for newcomers perf Performance-oriented issues m-debugging Related to system debuggability labels Sep 19, 2018
@jonhoo
Copy link
Contributor Author

jonhoo commented Sep 19, 2018

Also:

  • Read retries + time-to-completion
  • Domain frequency + processing time per destination node

@jbcden
Copy link

jbcden commented Oct 10, 2018

I have not really done this kind of thing before but I would be happy to give it a shot if someone can help point me in the right direction. I should also note that while I know a bit of Rust, I have not done a ton of actual work in it.

@jonhoo
Copy link
Contributor Author

jonhoo commented Oct 12, 2018

@jbcden Thanks for the offer! Thinking some more about this, I suspect this will actually require some relatively large-scale system refactoring to allow capturing all the metrics we care about. In particular, it's not immediately obvious to me how we store and report these metrics in a meaningful way and without overhead. I'm going to remove the good-first-issue tag for the time being.

@jonhoo jonhoo removed the good first issue Good for newcomers label Oct 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request m-debugging Related to system debuggability perf Performance-oriented issues
Projects
None yet
Development

No branches or pull requests

2 participants