Spawning uses eventlet to do non-blocking IO for http requests and responses. This means the server will scale to a large number of keep-alive connections easily.
However, Spawning also delegates requests using other forms of multiprocessing and is configurable to be useful in a wide variety of situations. Spawning supports multiple Python processes as well as a threadpool.
Single or Multiple Process
If your wsgi applications store state in memory, Spawning can be configured to run only one Python process. In this configuration your application state will be available to all requests but your application will not be able to take full advantage of multiple processors. Using multiple processes will take advantage of all processors and thus should be used for applications which do not share state.
Single or Multiple Worker Thread (or Worker Process)
If your wsgi applications perform a certain subset of blocking calls which have been monkeypatched by eventlet to cooperate instead (such as operations in the socket module), you can configure each process to run only a single main thread and cooperate using greenlet microthreads instead.
This can be useful if your application is very small and needs to scale to a large number of simultaneous requests, such as a COMET server or an application which uses AJAX polling.
However, most existing wsgi applications will probably perform blocking operations (for example, calling database adapter libraries which perform blocking socket operations).
Therefore, for most wsgi applications a combination of multiple processes and multiple threads will be ideal.
Graceful Code Reloading
By default, Spawning watches all Python files that are imported into sys.modules for changes and performs a graceful reload on change. Old processes are told to stop accepting requests and finish any outstanding requests they are servicing, and shutdown.
Meanwhile, the new processes are started and begin accepting requests and servicing them with the new updated code.
At no point will your website`s users see "connection refused" errors because the server will be continuously listening during reload.
What`s New in This Release: [ read full changelog ]
· Script for spawning renamed from "spawn" to "spawning" to avoid confusion
· Use O_APPEND when opening files when daemonizing
· Debian/Ubuntu init.d scripts using start-stop-daemon
· spawning.util module added to house methods that don`t belong elsewhere
· Update Spawning to use newer Eventlet API calls
· Properly handle errors when calling `setproctitle`
· Allow optional `eventlet.backdoor` bound to localhost
· Operate more cleanly with Eventlet`s websockets support with changes to
· eventlet.tpool integration
· Avoid passing certain objects through `eventlet.tpool.Proxy` when using
· threads for a performance gain
· Prevent leaking pipes when handling children processes
