Open s0undt3ch opened 4 years ago
Hello @s0undt3ch
Thanks for your proposal. It might be interesting, but I need a few more insights:
We have a project that starts a few child processes for which we run tests against.
What do you mean precisely? Are each unit tests launching a process? Or is it done by any fixture of yours? Or is it external (global setup done prior to run tests) ?
Are there any plans to track child processes statistics?
From what I've seen, it can be feasible to extend the collects and get an aggregated view for all child processes, but having each child processes metrics is far more complex:
Hack our own stats/metrics collector.
I am already working on a centralized API. Maybe we can discuss about it in order to track specific external conditions to your tests (if this is what you are looking for) ?
What do you mean precisely? Are each unit tests launching a process? Or is it done by any fixture of yours? Or is it external (global setup done prior to run tests) ?
These are actually integration tests, and the daemons are started/stopped by a fixture. The fixture currently has a session scope although we're switching it to a package scope. To retain, we don't start the daemons on a per-test basis.
From what I've seen, it can be feasible to extend the collects and get an aggregated view for all child processes, but having each child processes metrics is far more complex
What we currently do, which is just log the stats is to report each process cpu/mem stats and a separate state where we calculate that process cpu and memory (including each of its child, aggregated, not differentiated)
collecting such metrics is not free
Yes, we know.
Are you ready to sacrifice the measure correctness in order to extend the collect to child processes ?
We are, although your plugin might not. If implemented, it should be clear on the docs the performance penalty
Ok, thanks for the information.
I'll check if I can do something about that and retain such behavior in a purely optional way. However, I am unlikely to code it in the next few days.
Thank You!
And, of course, that's the nature of open-source :)
Pedro Algarvio @ Phone
A sexta, 13/03/2020, 17:27, Jean-Sebastien Dieu notifications@github.com escreveu:
Ok, thanks for the information.
I'll check if I can do something about that and retain such behavior in a purely optional way. However, I am unlikely to code it in the next few days.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CFMTech/pytest-monitor/issues/1#issuecomment-598832854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACJIEDAEKOEMRYBRK3QQTTRHJUITANCNFSM4LDQDF4Q .
We have a project that starts a few child processes for which we run tests against.
Are there any plans to track child processes statistics?
Describe the solution you'd like Include child processes stats on metrics.
Describe alternatives you've considered Hack our own stats/metrics collector.