raise slaverebooter's parallelization

RESOLVED FIXED

Status

defect
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: bhearsum, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Since fixing a bug in slaverebooter where we weren't actually waiting for graceful shutdowns, slaverebooter takes a lot longer to run. One way to improve this is to make it parallelize more. I had to reduce it to 4 threads when it initially landed because of issues with buildapi getting overloaded. But now that we have a better buildapi, I think we can increase it more. I'm thinking 8 threads for now, and maybe more if things continue to look good.

I plan to land this early in the morning one day so that I can keep a close eye on it.
Attachment #8380696 - Flags: review?(jhopkins)
Attachment #8380698 - Flags: review?(jhopkins)
Attachment #8380696 - Flags: review?(jhopkins) → review+
Attachment #8380698 - Flags: review?(jhopkins) → review+
Attachment #8380696 - Flags: checked-in+
Attachment #8380698 - Flags: checked-in+
Posted patch bump to 12Splinter Review
8 seems to be working fine without breaking buildapi, let's try even more :).
Assignee: nobody → bhearsum
Attachment #8382219 - Flags: review?(jhopkins)
Comment on attachment 8382219 [details] [diff] [review]
bump to 12

sure, what could go wrong ;)
Attachment #8382219 - Flags: review?(jhopkins) → review+
Attachment #8382219 - Flags: checked-in+
Even at 12 workers things are going fine. I think this is good enough for now - slaverebooter runs much more quickly than before.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.