-
Notifications
You must be signed in to change notification settings - Fork 4
guide for how to set limits for an application #28
Comments
This was the original/old proposal: A default approach is to assume that one's libp2p-using application is healthy. They can enable the resource manager, have the limits set to infinite, but also enable tracing. Run the applications for some number of hours/days and then parse the traced results with a script/notebook to set suggested limits. Below is a sample
|
Upon discussion 2022-06-03, rather than relying on trace files, we think it's a better to move the metrics story (libp2p/go-libp2p#1356 ) forward. Basically, use Prometheus to capturing metrics around all the things an operator cares about. This then makes it easy to:
|
Also per 2022-06-03, we're going to focus on getting alignment on the desired end state here before doing more implementation work. We'll draft up the limits we'd ideally like this guide/script to generate. We can then match that up against what's possible. |
Minimum goal: get a limiter configuration that would have allowed all the activity that happened, but not more. Nice to have (but not necessarily built by us): Give users the option to analyse / visualise the data further, to make informed modifications to that limiter config. |
I believe we've mostly turned to handling this with updated readme: https://github.com/libp2p/go-libp2p-resource-manager/blob/master/README.md (as done in #59) There are other updates to the readme we need to do though per #68 |
This issue has been resolved by our various docs updates. |
Done Criteria
A libp2p operator has a self-service guide for how to intelligently set limits for their application.
Why Important
Help operators know how to determine appropriate resource limits for their libp2p application.
User/Customer
Operator of an application using libp2p
Notes
This guide should be part of (or linked from #27).
Ideally the script/notebook would take an input (e.g., trace file, prometheus metrics) and some margin and then output the specific config keys that should be copy/pasted into their go-libp2p config.
It would be ideal to do a visual plot of resource usage over time so one can see if there's an apparent leak or need to increase the margin.
The text was updated successfully, but these errors were encountered: