Stacked cheaper algos

[prymitive]

I wanted to add new backlog handling feature to cheaper subsystem and this change would go the cheaper_busyness plugin, but then I though that we could have much better cheaper subsystem if we could stack multiple cheaper algos. This way all the backlog monitoring and worker count adjustments would go to separate plugin and there would be no need for single fat super-plugin reimplementing features that are already there.
In uwsgi_calc_cheaper() we could call a list of algos and then pick the biggest number and use that as needed_workers value.
This way cheaper_busyness can concentrate on busyness tracking, busyness might not indicate that we need more workers but backlog monitoring might want to start few.
It would be nice if each algo could have separate interval since backlog should be checked every master cycle, while busyness needs bigger intervals for smooth operation.

[unbit]

seems reasonable and pretty easy to accomplish. The only difference will be in having a dedicated struct for all of the internal counters (instead of having them in the uwsgi_server huge struct). The only additiono to your plan is allowing the user to invert the default behaviour and choose the lower non-zero value (in some scenario could be useful)

[prymitive]

I played a bit with it and come up with this
Usage: --cheaper-algo name[ interval],name[ interval],...

This idea needs a little bit of work, right now all algos fight with each other and in the end one plugin cheaps a worker while few seconds later another one respawns it.

[prymitive]

The only solution I could think of is to allow all algos to spawn new workers, but allow only one to cheap them.
But I'm not sure if making all those changes is worth it, maybe if we had a lot more cheaper algos than it would make sense.

[unbit]

Ok, i have finally managed to make a big rewrite of the whole master process.

Now it should be a lot easier to make customizations (like graceful reloading for mules) and to monitor specific situations.

I am writing lot of comments to the code and writing a bunch of tests, so it would need still a bit of time to have a solid solution.

I am working right now on the cheaper part, so stacked cheaper algos should be available pretty soon

[prymitive]

Ok, just take a look at my previous comments, multiple algorithms trying to come up with one number of workers that will make them all happy won't work very well. I would rather select one of them that will be able to stop workers while any could signal that additional are needed. Or just drop this concept and use code from cheaper busyness.
It's gonna be tricky

[unbit]

Why not simply taking the worst or the best (the user choose via config) value of the stacked functions ?

Ex.

listen_queue returns 1 worker needed
busyness returns 3 workers needed

if the user has choosen to use the worst value a single worker will be spawned, otherwise 3 workers will run.

[prymitive]

AFAIR I've tried that and still there were issues, I can retest it tomorrow if You want, so that I could provide more details what issues I had.

[prymitive]

I believe that the issues is that we have 3 types of values that cheaper algorithm can return:

< 0 - too much workers running, we should stop some
> 0 - not enough workers running, we should add some

those two above are working fine, but we also can return:

== 0 - but zero means both:
we have just the right amount of workers
and
I have no idea, ignore me

When an algorithm returns zero it can mean two things so it's hard to make a decision based on that. There are several cases where we get zero as return value, but we can't tell what case this is, examples:

• busyness returns zero since the load is between min and max user has set, so we should stick to that current number of workers despite the fact that other algos wants to cheap workers
• backlog returns zero since backlog is neither high or load, so other algos should decide

busyness algo works at full range of values it keeps track of while spare and backlog are only starting to work at low or high end of values, they are much more aggressive. Trying to make both types of algos to work together is going to have a lot of corner cases and I fear that it won't ever work the way user wants it.
Its gonna be much more predictable to have just one of the active at a time.

[prymitive]

Also each algo will need different interval to come up with a value, backlog should check as often as possible while busyness needs more time for accuracy.

[unbit]

Ok, so let's close that :) It looks like it is more easy to write ad-hoc algos instead of trying to combine them