; good resources for uwsgi configuration
; https://www.bloomberg.com/company/stories/configuring-uwsgi-production-deployment/
; https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

[uwsgi]
; fail to start if any parameter in the configuration file isn’t explicitly understood by uWSGI
strict=true

; This parameter prevents uWSGI from starting if it is unable to find or load your application module. Without this
; option, uWSGI will ignore any syntax and import errors thrown at startup and will start an empty shell that will return
; 500s for all requests. This is especially problematic because monitoring systems may observe that uWSGI started
; successfully and think the application is available to service requests when, in fact, it is not.
;
; uWSGI continues to start without your application loaded because it thinks you may load an application dynamically
; later. This is the default behavior because the dynamic loading of apps used to be common.
need-app=true

chdir=/etc/app
module=engine.wsgi:application

; The master uWSGI process is necessary to gracefully re-spawn and pre-fork workers, consolidate logs, and manage many
; other features (shared memory, cron jobs, worker timeouts…). Without this feature on, uWSGI is a mere shadow of its
; true self.
;
; This option should always be set to ‘on’ unless you are using the more complex “emperor” system for multi-app
; deployments or are debugging specific behavior for which you want uWSGI to be limited.
master=True

pidfile=/tmp/project-master.pid
http=0.0.0.0:8080
processes=5

; A feature of uWSGI that aborts workers that are serving requests for an excessively long time. Configured using the
; harakiri family of options. Every request that will take longer than the seconds specified in the harakiri timeout
; will be dropped and the corresponding worker recycled.
harakiri=60 ; seconds
harakiri-verbose=true

; Worker Recycling
; Worker recycling can prevent issues that become apparent over time such as memory leaks or unintentional states. In
; some circumstances, however, it can improve performance because newer processes have fresh memory space.
;
; uWSGI provides multiple methods for recycling workers. Assuming your app is relatively quick to reload, all three of
; the methods below should be effectively harmless and provide protection against different failure scenarios.
max-requests=5000 ; Restart workers after this many requests
max-worker-lifetime=3600 ; Restart workers after this many seconds
reload-on-rss=2048 ; Restart workers after this much resident memory
worker-reload-mercy=60 ; How long to wait before forcefully killing workers

; This option will instruct uWSGI to clean up any temporary files or UNIX sockets it created, such as HTTP sockets,
; pidfiles, or admin FIFOs.
;
; Leaving these files around can pose a problem under some circumstances, such as if a developer runs uWSGI as their
; own user, and takes ownership of these files. If the production user doesn’t have permission to delete those files,
; uWSGI may fail to function properly.
vacuum=True

buffer-size=65535
http-auto-chunked=True
http-timeout=620
http-keepalive=620
post-buffering=1

; uWSGI disables Python threads by default, as described in the Things to Know doc.
;
; By default the Python plugin does not initialize the GIL. This means your app-generated threads will not run. If you
; need threads, remember to enable them with enable-threads. Running uWSGI in multithreading mode (with the threads
; options) will automatically enable threading support. This “strange” default behaviour is for performance reasons, no
; shame in that.
;
; This is another option that might be the right choice for you. If it is, great! You’ll see a minor speed-up, but
; chances are high that you’ll be using a background thread for something. Without this parameter set, those threads
; won’t execute and some developer will be stuck in a weird place until they “discover” this feature. It’s best to
; leave it ‘on’ by default and remove it on a case-by-case basis.
enable-threads=true

; Till uWSGI 2.1, by default, sending the SIGTERM signal to uWSGI means “brutally reload the stack” while the
; convention is to shut an application down on SIGTERM. To shutdown uWSGI, use SIGINT or SIGQUIT instead. If you
; absolutely can not live with uWSGI being so disrespectful towards SIGTERM, by all means, enable the die-on-term
; option. Fortunately, this bad choice has been fixed in uWSGI 2.1

; You should enable this feature because it makes uWSGI behave in the way that any sane developer would expect. Without
; it, kill, or any tool that sends SIGTERM (such as some system monitoring tools) would attempt to kill uWSGI without
; success, confounding the operator of said tools.
die-on-term=true

; By default, uWSGI starts in multiple interpreter mode, which allows multiple services to be hosted in each worker
; process.
;
; Multiple interpreters are cool, but there are reports on some c extensions that do not cooperate well with them.
;
; When multiple interpreters are enabled, uWSGI will change the whole ThreadState (an internal Python structure) at
; every request. It is not so slow, but with some kind of app/extensions that could be overkill.
single-interpreter=true

; Prevent uWSGI from consuming too much memory: https://github.com/grafana/oncall/issues/1521
max-fd=1048576

logger=stdio
log-format=source=engine:uwsgi status=%(status) method=%(method) path=%(uri) latency=%(secs) google_trace_id=%(var.HTTP_X_CLOUD_TRACE_CONTEXT) protocol=%(proto) resp_size=%(size) req_body_size=%(cl)
log-encoder=format ${strftime:%%Y-%%m-%%d %%H:%%M:%%S} ${msgnl}