2b5554c079
# What this PR does Remove explicit request size limits both for uwsgi & Django. After this change, the effective request size limit will be 2.5MB as the default Django value for [DATA_UPLOAD_MAX_MEMORY_SIZE](https://docs.djangoproject.com/en/4.2/ref/settings/#data-upload-max-memory-size). ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not required)
101 lines
5.6 KiB
INI
101 lines
5.6 KiB
INI
; 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}
|