Home |
Last modified: 16-06-2020 |
Confusingly, "uwsgi" is both name of the binary application and one of the protocols it supports, while uWSGI is the name of the whole project because it started as a server supporting the WSGI protocol to run Python web applications. uwsgi also supports the FastCGI protocol, but the uwsgi protocol is faster for strings smaller than 64K.
Note that for light-load sites, uwsgi can't be used as a web server directly, with no need for a bigger front-end web server. In addition to its own binary protocol called (you guessed it) "uwsgi", uwsgi also supports FastCGI for higher loads.
If using Nginx as the front-end web server, "nging -V" will show if uwsgi was compiled in the application.
As of January 2014, the source code has moved to GitHub while the documentation is at ReadTheDocs.
Compiling requires installing a C compiler and Python.
uwsgi can run Lua scripts in two different ways: Plain ol' CGI for small sites (which requires installing the Lua interpreter or LuaJit), or WSAPI for heavier sites (WSAPI is to Lua what WSGI is to Python; The Lua interpreter will be compiled into the uwsgi binary.)
This is how to compile and run uwsgi as a stand-alone HTTP server to serve static files and run Lua scripts.
To avoid passing several parameters at the command prompt, use an INI file. Here's an example:
Launch uwsgi: ./uwsgi myapp.ini
http://uwsgi-docs.readthedocs.org/en/latest/Lua.html
http://uwsgi-docs.readthedocs.org/en/latest/HTTP.html
http://uwsgi-docs.readthedocs.org/en/latest/StaticFiles.html
ps aux | grep uwsgi
kill -SIGINT <PID of master process>
http://uwsgi-docs.readthedocs.org/en/latest/InternalRouting.html
uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
Note:
- Bind the stats socket to a private address (unless you know what you are doing), otherwise everyone could access it!
- You may want to use “uwsgitop” (just pip install it), which is a top-like tool for monitoring instances.
If you think about writing some init.d script for spawning uWSGI, just sit (and calm) down and check if your system offers you a better (more modern) approach.
Each distribution has chosen its startup system (Upstart, SystemD, etc.) and there are tons of process managers available: Supervisor, god, Circus, etc.
uWSGI will integrate very well with all of them (we hope), but if you plan to deploy a big number of apps check the uWSGI Emperor, it is the dream of every devops.
Always avoid running your uWSGI instances as root. You can drop privileges using the uid and gid options:
To build a basic uwsgi and only include the Lua plug-in: python uwsgiconfig.py --plugin plugins/lua core
Plugins can be compiled statically into the application or as shared libraries.
Graceful reload: uwsgi --reload /tmp/project-master.pid
Stopping the server: uwsgi --stop /tmp/project-master.pid
/tmp/uwsgi-2.0# ./uwsgi –show-config
unable to load configuration from –show-config
If an HTTP request has a body (like a POST request generated by a form), you have to read (consume) it in your application. If you do not do this, the communication socket with your webserver may be clobbered. If you are lazy you can use the post-buffering option that will automatically read data for you. For Rack applications this is automatically enabled.
If you plan to use UNIX sockets (as opposed to TCP), remember they are standard filesystem objects. This means they have permissions and as such your webserver must have write access to them.
Common sense: do not run uWSGI instances as root. You can start your uWSGIs as root, but be sure to drop privileges with the uid and gid options.