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

processing_rate is a multiplier and not absolute number #77

Open
MeLight opened this issue Oct 14, 2015 · 5 comments
Open

processing_rate is a multiplier and not absolute number #77

MeLight opened this issue Oct 14, 2015 · 5 comments

Comments

@MeLight
Copy link

MeLight commented Oct 14, 2015

When I pass "processing_rate":1 as part of mapper_params and examine the logs of /mapreduce/worker_callback I see that each worker callback processes 8 entities each time. If I set "processing_rate":2 each callback will process 16 entities. On another project I've worked on, the numbers were 15 and 30 (for processing_rate of 1 and 2). So I conclude that processing_rate param is a multiplier.

  • Where can I set the actual value?
  • What makes it change from project to project?
@tkaitchuck
Copy link
Contributor

processing_rate really should be removed. It's a throttle to restrict the rate items are processed. If you don't want to artificially slow things down, then don't set it.

@MeLight
Copy link
Author

MeLight commented Oct 16, 2015

So there's no way of knowing how many entities each shard will process?

@tkaitchuck
Copy link
Contributor

It will process as many as it can in the configured slice interval. Is there some reason you want to restrict it?

@MeLight
Copy link
Author

MeLight commented Oct 25, 2015

I want to restrict the rate to entity-per-task so that it is easier to analyze the logs and track errors.

@tkaitchuck
Copy link
Contributor

Then, yes, that is the setting you want. All changes to the value should produce a linear change in the rate.

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