Dynamically increase

Question

Dynamically increase

pjebs opened this issue 9 years ago · comments

How can I dynamically increase number of workers?

Ashley Jeffs · Answer 1 · Mon Jun 22 2015 20:44:05 GMT+0800 (China Standard Time)

Hey @pjebs, I've been thinking about this and there's a number of ways that this could be implemented depending on use case. What in particular would you need a dynamic pool for? Any pseudocode examples would be great.

pj · Answer 2 · Mon Jun 22 2015 21:05:46 GMT+0800 (China Standard Time)

This is my use-case:

https://github.com/pjebs/beanstalkd-worker

I have a constant: NUM_WORKERS_MULTIPLIER which dictates how many workers get generated:
workers := make([]tunny.TunnyWorker, runtime.GOMAXPROCS(runtime.NumCPU())*NUM_WORKERS_MULTIPLIER)

I was just thinking if it was possible to dynamically increase/decrease this number so if I measure CPU usage I can lower the number dynamically and vice-versa.

pj · Answer 3 · Mon Jun 22 2015 21:05:53 GMT+0800 (China Standard Time)

Good library by the way!

Adam Weiner · Answer 4 · Fri Feb 05 2016 02:36:16 GMT+0800 (China Standard Time)

+1

@Jeffail An additional use case for this would be querying an API that allows n concurrent connections, where n changes based on the load the API is currently under and is reported with each API response.

Marcin Szydelski · Answer 5 · Wed May 10 2017 20:02:08 GMT+0800 (China Standard Time)

Also +1. I want to use this lib for managing the external workers. I should handle the situation where worker dies or I need to dynamically connect more workers to process higher traffic.

Adam Stankiewicz · Answer 6 · Thu Dec 07 2017 03:37:18 GMT+0800 (China Standard Time)

If someone knows good alternative with ability to change concurrency, please write a comment

Ashley Jeffs · Answer 7 · Mon Jan 01 2018 01:43:05 GMT+0800 (China Standard Time)

Hey everyone, the tunny API couldn't have handled this at all gracefully without a significant restructure, so I've performed a full rewrite that adds this along with a few other fixes and QOL changes. It's currently on a branch found here: https://github.com/Jeffail/tunny/tree/feature/refactor-api

I'm going to tag the current state of tunny at 0.0.1 and eventually merge this new API into master under the tag 0.1.0. Obviously this will potentially have a huge impact on users that aren't vendored, so I'm interested in hearing any advice on doing this gracefully, if it's even possible.

pj · Answer 8 · Mon Jan 01 2018 06:36:29 GMT+0800 (China Standard Time)

Not possible.

Ashley Jeffs · Answer 9 · Wed Jan 03 2018 03:59:41 GMT+0800 (China Standard Time)

I'm giving it a week or so before committing the changes to master and have added an issue for guiding anyone that is impacted #19.

I also ran a quick benchmark to check for performance regression:

BenchmarkOld-8            100000             18496 ns/op                                                                                                                                                                               
BenchmarkNew-8            200000              6373 ns/op

So we're looking good, as expected really since I'm no longer using reflection.

Ashley Jeffs · Answer 10 · Wed Jan 10 2018 02:35:32 GMT+0800 (China Standard Time)

This has now been merged into master.