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

Modify #time to support a "count" option. #48

Open
pnomolos opened this issue May 14, 2017 · 2 comments
Open

Modify #time to support a "count" option. #48

pnomolos opened this issue May 14, 2017 · 2 comments

Comments

@pnomolos
Copy link

I have to time some bulk operations and it's not viable to push to statsd every iteration of the loop. However, what would be nice is something like the following:

$statsd.time('accounts.activate', { count: accounts.length } ) { process_accounts(accounts) }

Internally this would change time to something similar to the following:

def time(stat, opts={})
  count = [opts.fetch(:count, 1), 1].max
  start = Time.now
  return yield
ensure
  time_since(stat / count, start, opts)
end

I can open a PR if this sounds like a good idea :)

@pnomolos pnomolos changed the title Modify time to support a "count" option. Modify #time to support a "count" option. May 14, 2017
@degemer
Copy link
Member

degemer commented May 17, 2017

Hello @pnomolos, thanks for the suggestion!

The main/only downside of this approach is that we lose granularity, since time calls are aggregated as an histogram in dogstatsd (with avg, median, percentiles), so we would send pre-aggregated data to dogstatsd.

Would the batch function work for you? It should greatly reduce the number of push to statsd while keeping the full data.

What do you think?

@pnomolos
Copy link
Author

@degemer Unfortunately that isn't viable in my use-case. In the example above, process_accounts(accounts) is a call out to a third-party library, but the processing time should scale linearly with the number of accounts.

In my case I'm running about 600 of these jobs per day (with varying numbers of accounts per job) and I'm trying to get a baseline for the time it takes to do the jobs, normalized by the number of accounts that are being processed.

If I was able to add a call per-account I definitely would, but that's not the case here :(

pudiva pushed a commit to pudiva/dogstatsd-ruby that referenced this issue Jun 5, 2023
* Remove Howie config

* Remove Howie artifacts

* Update issue commands

---------

Co-authored-by: howie-work-legacy[bot] <85196128+howie-work-legacy[bot]@users.noreply.github.com>
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

No branches or pull requests

2 participants