We use gunicorn on fprocess command ENV fprocess="gunicorn -c gconfig.py index:app"
The of-watchdog appear the Upstream HTTP request error while the gunicon worker restart by the max_requests setting.
I use ab to stress test on of-watchdog and gunicorn endpoint, and only happened on the POST method.
The of-watchdog endpoint had some failed requests while the gunicorn worker restart.
But direct sending requests to gunicorn endpoint seems no problem.
I have a solution proposal, could we make the keep-alive to be an optional argument.
Let the user decide to turn on or turn off for their use cases.
@alexellis Does it make sense to you?
We use gunicorn on fprocess command
ENV fprocess="gunicorn -c gconfig.py index:app"
The of-watchdog appear theUpstream HTTP request error
while the gunicon worker restart by themax_requests
setting.I use
ab
to stress test on of-watchdog and gunicorn endpoint, and only happened on thePOST
method. The of-watchdog endpoint had some failed requests while the gunicorn worker restart. But direct sending requests to gunicorn endpoint seems no problem.Expected Behaviour
Current Behaviour
Possible Solution
Steps to Reproduce (for bugs)
code:
gunicorn config
Steps
you may see some failed requests due to the gunicorn worker auto-restart.
failed log
stress test on gunicorn endpoint, increase the concurrent requests or total requests as you want
There are no failed requests on gunicorn endpoint.
Remove the
max_requests = 10
setting from gconfig.py, run step 3 again. No restarts on gunicorn workers, requests are all success.Context
of-watchdog have the retry or fix the connection close as well as other HTTP clients do.
Your Environment
Docker version
docker version
(e.g. Docker 17.0.05 ):19.03.8
Are you using Docker Swarm or Kubernetes (FaaS-netes)? No
Operating System and version (e.g. Linux, Windows, MacOS): MacOS
Link to your project or a code example to reproduce issue: