Hi William,
Thanks for starting this discussion.
Your email raise several aspects (How, for whom,..) and I think a way to
start would be to write down what we want.
A need is from a given workload to determine where we are spending time
as a way to determine where to invest.
An other need is to collect metrics at operation level.
From the how perspective, we can rely on external tools (stap+scripts),
or internal tool (like the plugin you described+scripts). Of course we
can also do some enhancements inside DS (like adding probes) to help
external tools. I have no strong opinion if an approach is better than
the other but I think it also depends what you want to perform.
best regards
thierry
On 10/08/2018 12:37 PM, William Brown wrote:
Hi there,
In a ticket Thierry and I mentioned that we should have a quick discussion about ideas for profiling and what we want it to look like and what we need. I think it’s important we improve our observation into the server so that we can target improvements correctly,
I think we should know:
* Who is the target audience to run our profiling tools?
* What kind of information we do want?
* Potential solution for the above.
With those in mind I think that Thierry suggested STAP scripts.
* Target audience - developers (us) and some “highly experienced” admins (STAP is not the easiest thing to run).
* Information - STAP would largely tell us timing and possibly allows some variable/struct extraction. STAP does allow us to look at connection info too a bit easier.
I would suggest an “event” struct, and logging service
At the start of an operation we create an event struct. As we enter - exit a plugin we can append timing information, and the plugin itself can add details (for example, backend could add idl performance metrics or other). At the end of the operation, we log the event struct as a json blob to our access log associated to the conn/op.
* Target - anyone, it’s a log level. Really easy to enable (Think mailing list or user support, can easily send us diagnostic logs)
* Information - we need a bit more work to structure the “event” struct internally for profiling, but we’d get timings and possibly internal variable data as well in the event.
I think these are two possible approaches. STAP is less invasive, easier to start now, but harder to extend later. Logging is more accessible to users/admins, easier to extend later, but more work to add now.
What do we think?
—
Sincerely,
William
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
