It's a shame you are not using a *nix os, because you could have then
used uWSGI (http://projects.unbit.it/uwsgi/).
Feature list:
Current core features are
* written totally in C
* very fast (and simple) communication protocol for webservers
integration (apache2
<http://projects.unbit.it/uwsgi/wiki/RunOnApache2>,nginx
<http://projects.unbit.it/uwsgi/wiki/RunOnNginx>,cherokee
<http://projects.unbit.it/uwsgi/wiki/RunOnCherokee>andlighttpd
<http://projects.unbit.it/uwsgi/wiki/RunOnLighttpd>modules available)
* low memory footprint (thanks to the evil premature optimizations)
* support for multiple application in the same process/domain
* a master process manager that will allows you to automatically
respawn processes and monitor the stack status
* preforking mode to improve concurrency
* address space and rss usage reports
* advanced logging (even networked, seeUdpLogging
<http://projects.unbit.it/uwsgi/wiki/UdpLogging>)
* static file serving via sendfile() (where available)
* portability (tested on Linux 2.6, Solaris/OpenSolaris, OpenBSD,
NetBSD, DragonflyBSD, FreeBSD, MacOSX and Haiku)
* support for funny architectures like SPARC64 or ARM
* support for threads (configurable, available from 0.9.7-dev)
* cgi mode for lazy users or ugly webservers (example cgi
includedhere
<http://projects.unbit.it/uwsgi/browser/contrib/uwsgi_client.c>andhere
<http://projects.unbit.it/uwsgi/browser/contrib/uwsgi_dynamic_client.c>)
* harakiri mode for self-healing
* vector based I/O to minimize syscall usage
* hot-add of applications. SeeDynamicApps
<http://projects.unbit.it/uwsgi/wiki/DynamicApps>
* on the-fly configuration parameters. SeeManagementFlag
<http://projects.unbit.it/uwsgi/wiki/ManagementFlag>
* 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)
* configurable buffer size for low-memory system or to manage big
requests
* customizable builds (you can remove unneeded functionality)
* intelligent worker respawner wih no-fork-bombing policy
* limit requests per worker
* process reaper for external process managers (as daemontools).
Avoids zombie workers.
* Per-request modifier for advanced users (SeeRunOnNginx
<http://projects.unbit.it/uwsgi/wiki/RunOnNginx>for an example
usage, anduwsgiProtocol
<http://projects.unbit.it/uwsgi/wiki/uwsgiProtocol>for the
modifiers list)
* UNIX and TCP socket support
* Graceful restart of worker processes and hot-plug
substitution/upgrade of theuWSGIserver usingSignals
<http://projects.unbit.it/uwsgi/wiki/uWSGISignals>. SeeuWSGIReload
<http://projects.unbit.it/uwsgi/wiki/uWSGIReload>
* A shared memory area to share data between workers/processes.
SeeSharedArea <http://projects.unbit.it/uwsgi/wiki/SharedArea>
* An integratedSpooler
<http://projects.unbit.it/uwsgi/wiki/Spooler>for managing long
running task.
* Message exchanging (viauwsgiprotocol) for easy-implementation of
distributed applications (look atClusteredExamples
<http://projects.unbit.it/uwsgi/wiki/ClusteredExamples>)
* Get statistics of all the workers using theEmbeddedModule
<http://projects.unbit.it/uwsgi/wiki/EmbeddedModule>
* Integrated Async/EventedProxy
<http://projects.unbit.it/uwsgi/wiki/Proxy>for load-balancing and
healtchecking of big clusters (from version 0.9.5)
* Address space usage limiting (from version 0.9.5)
* integrated SNMP agent and nagios-friendly output (from version
0.9.5) SeeUseSnmp <http://projects.unbit.it/uwsgi/wiki/UseSnmp>
* VirtualHosting
<http://projects.unbit.it/uwsgi/wiki/VirtualHosting>mode (from
version 0.9.6)
* Embedded threadedHTTP server
<http://projects.unbit.it/uwsgi/wiki/HTTPserver>for easy
development and testing (from version 0.9.6)
TODO/Working on
* integrated support for wsgi middleware (is it really useful ?)
* put some more code comments to gather external developers ;)
* better anti-fork bombing policy (lesser dumb)
* advanced conditional logging (already available in 0.9.6.5, more
to come in 0.9.7)
* Linux cgroups integration (work already started in 0.9.7-dev)
seeUseCgroups <http://projects.unbit.it/uwsgi/wiki/UseCgroups>
* SSL support (with certificate client authentication) to allow
remote management of theuWSGIstack
* support for multiple listening sockets (already available in
mercurial repository, simply add more --socket options)
* Web3 (PEP-444) (already available in mercurial repository)
* IPv6 support (targeted at 0.9.7 release)
* SCTP support (experimental support is in 0.9.5 trunk, but no
performance gain, still hard work needed)
* Event Dispatcher (execute callable on external events like file
changes, bonjour/avahi/dnssd message, timers...) (work started in
0.9.6-dev, targeted at 0.9.7)
* hash table overSharedArea
<http://projects.unbit.it/uwsgi/wiki/SharedArea>(for ultra-fast
integrated caching)
* AIX, Hurd, MorphOS support (targeted at 0.9.7)
* Better Rack/RubyOnRails plugin
* Async Mode optimizations (work already started in 0.9.7-dev)
* Threading mode support (already available in mercurial repository,
simply add --threads <N> to spawn N thread cores)
* fully pluginize python support to make a total language agnostic
server (main feature of 0.9.7 release)
* Move embedded http server from threads to evented
* Add Message Queuing system (with publish/subscribe) on top of
theSpooler <http://projects.unbit.it/uwsgi/wiki/Spooler>(and
export it via STOMP protocol to third party software)
On 01/12/2010 15:26, Javier Guerra Giraldez wrote:
On Wed, Dec 1, 2010 at 6:43 AM, ashdesigner<antony.shash...@gmail.com> wrote:
The only undiscovered issue to us is whether we can launch a heavy
loaded website in Django under Windows (IIS) + MSSQL. Would appreciate
any comment please.
a WSGI plugin for IIS would be the best answer; but there's nothing
wrong with FastCGI. properly managed can sustain as high load as
anybody else.
unfortunately, the most common FastCGI->WSGI adapter (flup) is quite
good and performant; but limited in terms of dynamic process/thread
lifetime managing. a more 'modern' approach could be gunicorn or
Tornado. since both of them handle HTTP->WSGI, your IIS frontend
would have to proxy those requests, but i guess that's a standard
feature of any webserver
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
