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

Add optional pool utilization stats #141

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

shizzard
Copy link

@shizzard shizzard commented Nov 27, 2020

I added a way to monitor approximate pool utilization.
TL;DR: When stats collection is enabled, pool manager will collect stats regarding workers utilization. It will report utilization in percentage. Stats reported will show pool utilization in between poolboy:stats/1 calls.

New configuration option added: {stats, boolean()}. Default value: false.

When option set to true, pool manager process will collect time duration workers being checked out. This is done by simply adding yet another duration to a total time worker was busy doing stuff.

When poolboy:stats/1 is called, manager will report collected values (observed period, total workers busy time, original pool size); it will reset observing period time and total workers busy time. Approximate pool utilization calculations are done on caller side: utilization is a float 0.0..1.0 when no overflow allowed, and 0.0..N if overflow is allowed.
NB: when pool is configured with overflow allowed, pool utilization may go over 1.0. This will, obviously, indicate that pool is overflown.

I consider this code to be quite cheap to use in heavily loaded pools. It will allow to monitor pool utilization in more precise manner; pool utilization then may be reported to some monitoring system (e.g. prometheus/grafana, etc.).

Let me know if you like the idea or if this code is good enough to be merged.

test/poolboy_tests.erl Outdated Show resolved Hide resolved
@shizzard
Copy link
Author

shizzard commented Nov 27, 2020

Looks like I will need to support erlang pre-18, since new time API is available starting from erlang 18.0 / erts 7.0.

@shizzard
Copy link
Author

@Vagabond hi!
Do you have any described process of accepting/declining pull-requests?
As I can see, last accepted PR was merged in October 2018. No rush here, I just want some transparency.
I want to use this code in my project, but I don't really want to support yet another fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant