Downgrade python

[waghanza]

Hi,

This PR downgrade python, 3.6 instead of 3.7, as uvloop is not compatible with 3.7 (yet ?)
MagicStack/uvloop#178

@frnkvieira As far a I understand workers (at least for app I design) SHOULD be 1 per core. Why vibora spread on cpu_count() + 2 by default

@see https://github.com/vibora-io/vibora/blob/master/vibora/server.py#L282

@greed2411 I can see that on the implementation, you specified headers.
Is there any idea behind that ? (there is no header in doc examples).

Regards,

[frnkvieira]

@waghanza From my tests, this is the best setup for Vibora if you take the average of different benchmarks. There is no science on this and never will, the optimal number of workers is always dependent on the application workload. In my own benchmarks I setup 1 worker per core for each framework to make it fair as you should keep doing. Hope it makes sense :)

[waghanza]

@frnkvieira I understand you use 1 worker per core on you're benchmarks, but should not it be the default ? I mean, at least having a huge workload it is enough no ?

[frnkvieira]

@waghanza there is a difference between "enough" and "optimal", as I said, this is a personal choice based on my experience but usually throwing a little more workers than CPU cores leads to better results (in average between different kinds of benchmarks, not on hello-world ones). If you look at Gunicorn they also seems to throw one "extra" worker on their formula. (http://docs.gunicorn.org/en/stable/design.html#how-many-workers).

[waghanza]

@frnkvieira sure default behaviour is the core team choice 😜

moreover, vibora seems to be more performing with the default (for this project use case)

Workers	Requests per s
Default	142554.00
1 per CPU	134763.00