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

Collect metrics through Actor wrapper? #27

Open
strohel opened this issue Feb 20, 2021 · 0 comments
Open

Collect metrics through Actor wrapper? #27

strohel opened this issue Feb 20, 2021 · 0 comments
Labels
API Relates to public API surface

Comments

@strohel
Copy link
Member

strohel commented Feb 20, 2021

If I look correctly, metrics are currently only collected in System::run_actor_select_loop() -> recv(addr.message_rx) -> msg => arm. That opens a possibility to collect the metrics solely inside Actor::handle(), without any explicit involvement of System. For code reuse, this can be implemented through some MeteredActor wrapper around actual Actor. To achieve the same ergonomics as the current state, a MeteredSystem (containing System) could be introduced that would wrap each passed actor during spawn() (arriving de-facto near the starting point).

Potential advantages:

  • The "core API" would be free of this "specific" concern - who doesn't care about metrics wouldn't have to know about them. "Only pay for what you use".
  • The difference between System and SystemHandle would cease to exist, and these two could be merged into a single type. This difference was a source of light confusion when I initially read the API docs and code.
  • Metrics collection could be enabled only for some actors, not "all or none". (this is currently achievable by spawning multiple systems, with some slight resulting inconvenience).
  • Would allow more elaborate metrics collection patterns, like recording them every 10 messages, etc.

Disadvantages:

  • Too many wrappers could make things like reasoning, debugging, rustc errors more complicated. (I would expect that rustc is able to compile-out the abstractions for zero runtime overhead though).
  • Not sure if this fits with future plans for metrics (related: Improve metrics collection and reporting #7).
  • more..?

This is spiritually similar to #26 - I have somehow fallen for Actor wrappers. ;-)

@strohel strohel added the API Relates to public API surface label Feb 20, 2021
This was referenced Feb 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Relates to public API surface
Projects
None yet
Development

No branches or pull requests

1 participant