|Version 113 (modified by unbit, 4 years ago) (diff)|
uWSGI is a fast (pure C), self-healing, developer-friendly WSGI server, aimed for professional python webapps deployment and development.
Current features are
- written totally in C
- very fast communication protocol for webservers integration (apache2, nginx and cherokee module included)
- low memory footprint (thanks to the evil premature optimizations)
- support for multiple application in the same process/domain
- preforking mode to improve concurrency
- address space and rss usage reports
- advanced logging
- static file serving via sendfile()
- portability (tested on Linux 2.6, FreeBSD and MacOSX 10.5)
- support for python-generated threads (configurable)
- cgi mode for lazy users or ugly webservers (example cgi included)
- harakiri mode for self-healing
- vector based I/O to minimize syscall usage
- hot-add of wsgi applications. See DynamicApps
- static configuration option based on a simple xml file (or a simple python module using ApplicationsDict)
- integrated profiler (cProfiler)
- support for multiple interpreter mode
- support for python2.4, python2.5 and python2.6
- big (professional) user-base (hundreds of production ready wsgi apps) thanks to its main development managed by the Italian ISP Unbit
- commercial support available (contact Unbit for informations)
- all code is under GPL2 (but you can buy a commercial license if you want to modify it without releasing source code)
- socket failover in apache module to increase availability (from version 0.9.1)
- configurable buffer size for low-memory system or to manage big requests (from version 0.9.1)
- print statistics sending SIGUSR1 to processes (from version 0.9.1)
- ROCK_SOLID compilation flag for paranoid users (no threading, multiple interpreters and potentially dangerous options). (form version 0.9.2)
- intelligent worker respawner wih no-fork-bombing policy (from version 0.9.2)
- limit requests per worker (from version 0.9.2)
- process reaper for external process managers (as daemontools). Avoids zombie workers. (from version 0.9.2)
- Per-request modifier for advanced users (See RunOnNginx for an example usage)
- TCP support (from version 0.9.2)
- support for python3 (from version >0.9.2). Warning, the current WSGI standard does not mention UNICODE support, and python3.x support in general. Look at RunOnPython3k
- fully integrable in Twisted environments using the included (from version >0.9.2) client resource adapter. See RunOnTwisted
- Graceful restart of worker processes and hot-plug substitution/upgrade of the uWSGI server using Signals. See uWSGIReload
- A shared memory area to share data between workers/processes (from version 0.9.3). See SharedArea
- Tomcat handler to integrate python apps in J2EE environments (from version 0.9.3)
- Support for virtualenv (from version 0.9.3)
- Nginx 0.7.x module (from version 0.9.3). See RunOnNginx
- An integrated Spooler for managing long running task and message exchanging in cluster environments. (from version 0.9.4, currently hardly working on it...)
- integrated support for wsgi middleware
- virtualhost mode to serve multiple domains with only one process (with one python interpreter for domain)
- put some more code comments to gather external developers ;)
- pluginIZE the protocol manager to supports standard protocols (scgi, fastcgi, ajp, http...)
- minimize global vars usage to start thinking on threading mode (warning, still discussing)
- mingw32 support (still discussing as it will end in a very basic/less useful product)
- better anti-fork bombing policy (lesser dumb)
- support for mixed environments (little-endian/big-endian) (scheduled for the 0.9.4 release, ready in current trunk)
- support for OpenBSD (ready in current trunk)
- support for OpenSolaris (ready in current trunk)
- Default universal Makefile (ready in current trunk)
- Get rid of libxml2 (and XML configuration in general) using it as a compilation flag (automatically enabled/disabled by the Makefile).
Current (stable) release:
(released on 20091129)
mercurial repository (trunk)
hg clone http://projects.unbit.it/hg/uwsgi
You can view some configuration example at the Example page
Why ? There are already mod_wsgi, flup and lot of protocols (fastcgi, scgi...). Is this faster or simpler to configure ?
-- Disclaimer, do not take seriously the next two statements, we are brutal people... --
Stop acting as a Rails user ! Deploy of python web applications is not a problem.
No need of ultra-hypeous next-fu*king-useless almost-working deploy technology.
-- end of brutal part --
The challenge in the python-world is now "features", uWSGI is a feature rich application, developer (and administrator/security paranoid/business environments) friendly. Stop.
Other deploy systems, works very well, this one does only more things.
What about the protocol ?
The uWSGI protocol is derived from scgi but with binary string length rapresentation and a 4 byte header that includes the size of the var block (16 bit le) and a couple of general-purpose bytes (for now they can be used as a per-request modifier).
header (4 bytes, size is in little endian) :
env vars follow (this is a block of the size specified in the header, string size is 16 bit little endian):
It could be used for every web technology:
A ruby-rack module that use the uwsgi protocol is on work at http://projects.unbit.it/hg/urack/
...And no, we are not reinventing the wheel. We are at low-level, binary management is easier and cheaper than string parsing, and we need every bit of power for our projects.
Can i use it in cluster environments ?
Yes, starting from version 0.9.2 you can bind uWSGI on a TCP port. For example, using the UWSGI Cherokee handler you can specify different uWSGI server running on different systems, or you can use the integrated upstream load balancer of Nginx. A future version of mod_uwsgi for apache will include an integrated load-balancer.
Why all those timeout configuration flag ?
Good timeout choosing is the key for high-availability. Do not trust network applications that do not permit you to choose a timeout.
Why most of the funny features are disabled on UNBIT systems ?
Because most of the self-healing functions and resource management are integrated in the platform.
How can i buy commercial support for my company ?
Write a mail to info at unbit.it with the keyword 'uWSGI' in the subject. The mail should includes Company information and obviously your specific request. We will reply ASAP
Does it will allow me to run python apps on my ancient closed-mind isp ?
Probably not. The uWSGI server has no support for automagic configurations.
How does it compare to solutions like Passenger ?
Passenger is a really great product, but we are not interested in automagic configurations and extreme user-friendlyness. We are hacker/geek/tech/business - friendly, and we are really bad at writing software for "people" ;)
What about mod_wsgi (the apache one)
Its "daemon mode" is wonderful, and it is probably one of the best way to deploy python apps. We are against embedding interpreters in webservers so we are against its "non-daemon mode". A bit of uWSGI code is based on mod_wsgi ideas.
It is GPL2, can i use it in commercial products ?
Yes, the uWSGI server only executes your applications, it does not link with them in any way (even if we expose the uwsgi module to your app). The problem could rise on webservers integration modules, but we will try to choose the best license for them. Please if you are a software license expert subscribe to the mailing-list and post your ideas.
Where are the benchmarks ?
Are hidden in a secret crypt on a secret island on a secret planet. If you are a benchmark fan you can try to find them. Sorry, we do benchmarks only for regressions test, most of the time people want becnhmarks only for starting flames. If you really need them for your business you can search on some mailinglist (for example on the cherokee list we posted a simple benchmark with flup), or ask someone (else) to do them for you.
Harakiri mode ???
We host hundreds of unreliable WSGI apps on our servers. All of them run on hardly (at kernel level) constrained environments where having processes blocked for an implementation error will result on taking down an entire site. The harakiri mode has two operational mode (from version 0.9.4): one that we define 'raw and a bit unreliable' (used for simple setup without a process manager) and another one that we define 'reliable' that depends on the presence of the uWSGI process manager. The first one sets a simple alarm at the start of every request. If the process get the SIGALRM it terminates itself. We call this 'a bit unrealible' cause your app or some module you use could overwrite (or simply cancel) the alarm with a simple call to alarm(). The second one use a master process shared memory area (via mmap) that maintains statistics on every worker on the pool. A the start of every request, the worker set in its dedicated area a timestamp representing the time after the process will be killed. After every successfull request this timestamp is zeroed. If the master process finds a worker with a timestamp in the past it will kill it.
Does my application will run faster with uWSGI ?
Probably not. The biggest player in webapps deployment is the webapp itself. If you want a faster environment optimize your code or use technics like clustring or caching. We say that uWSGI is fast cause it introduces a very little overhead in the deploy structure.
What are the most important options for performance and robustness of the uWSGI environment ?
If you do not want to use the ROCK_SOLID distribution, the most "dangerous" flags are the multiple-interpreter and threading stuff. If you want to use uWSGI for only one application turn off multiple-interpeter mode and threading.
Is it a FastCGI/SCGI + FLUP on steroids ?
Probably. From a low-level point of view they work in the same way. Do not spend too much time looking at the communication protocol (as a lot of people do) as the hard work is done by the uWSGI server that tries to manage your apps in the best possibile way.