Secrets of a WSGI master.
Why Stack Overflow recommends it
Stack Overflow users, including mod_wsgi's author himself, link it when answering questions about mod_wsgi daemon mode, threads, processes and handling abnormal conditions.
Recommended by 2 people across 4 different months, 2017 to 2022.
What it is
Graham Dumpleton, the author of mod_wsgi, gives a 30-minute PyCon AU 2017 talk on getting more out of WSGI deployments. It covers mod_wsgi configuration options and how to tune and harden Python web servers running under Apache.
What people said
Recommends Graham Dumpleton · 2017-08 · Stack Overflow · on “What determines which ErrorLog Apache logs an error to (httpd.conf vs. vhost.conf)?”
I can only suggest you upgrade to the latest version of mod_wsgi. Version 3.4 is over 5 years old. Don't use the operating system packages they are out of date and have never been supported as I don't create those packages, use ``pip install mod_wsgi`` and then ``mod_wsgi-express module-config`` to generate snippet to put into Apache configuration to load the module. See [LINK] and my recent talk [this video]
Recommends Graham Dumpleton · 2017-09 · Stack Overflow · on “Apache mod_wsgi better configuration”
There are a whole bunch of options to ``WSGIDaemonProcess`` which can be set to help provide a system which can better deal with abnormal conditions. See [this video] As to improving performance, it is impossible to give guidance unless you have metrics available about how your application performs. How long requests take. Whether CPU or I/O bound and various other things.
Recommends Graham Dumpleton · 2018-04 · Stack Overflow · on “Apache mod_wsgi django enable multi-thread multi-process”
Setting a high number of threads in Python is usually a bad idea because of the Python GIL. And doing benchmark testing where you excessively overload the system is even worse as it jut exacerbates things and gives unreliable results. I'd recommend not running a Python web server which uses threading at over 40-60% capacity because once you push throughput higher, especially if more CPU bound, then things go rapidly down hill. Benchmarks which send max requests, do this very quickly and so are meaningless. I would suggest watching the following two conference talk videos which goes into some of the issues. [LINK] [LINK] As a general rule of thumb, do the following: Use daemon mode. Disable e
Recommends Calvin He · 2022-04 · Stack Overflow · on “Apache keeps reporting "python error: not main interpreter" on running django WSGI”
The answer from: [LINK] The first suggestion change is instead of using: WSGIDaemonProcess ${url} user=${project-user} group=${project-group} python-path=${RootPath}/web/${url}/ python-home=${RootPath}/web/envs/${venv} display-name=${project} processes=3 threads=100 request-timeout=600 WSGIProcessGroup ${url} WSGIScriptAlias / ${RootPath}/web/${url}/${app}/wsgi.py process-group=${url} use: WSGIDaemonProcess ${url} user=${project-user} group=${project-group} python-path=${RootPath}/web/${url}/ python-home=${RootPath}/web/envs/${venv} display-name=${project} processes=3 threads=10 request-timeout=600 WSGIScriptAlias / ${RootPath}/web/${url}/${app}/wsgi.py process-group=${url} application-group
Cites Carel · 2019-11 · Stack Overflow · on “Recommended place for a Django project to live on Linux”
File Hierarchy System @Andy Hayden really states where not to place ones code. The File Hierarchy System (FHS) [LINK] implicates the following structure; PATH maps to PACKAGE or PROVIDER (It is recommended that parties providing multiple packages should use PROVIDER/PACKAGE ) : /etc/opt/PATH # FHS location for /opt configuration files /opt/PATH # FHS location for PROVIDER or PACKAGE name /var/opt/PATH # FHS location for /opt variable storage The FHS expects /opt/PATH to contain all the material necessary for the successful execution of ones package so it seems prudent to setup the following symbolic links /etc/opt/PATH to /opt/PATH/etc /var/opt/PATH to /opt/PATH/var This provides a good basi