| License: | MIT |
|---|---|
| Project-Label: | asynwsgi |
| Version: | 0.4dev4-r436-service-api |
| Author: | Robin Bryce |
| Author-email: | robinbryce@gmail.com |
| Description: | A suspiciously quick, pure python (2.5 only), asynchronous WSGI server, implemented using asynchronous I/O and non blocking sockets. |
| Copyright: | Copyright (c) 2007 Robin Bryce |
| Classifiers: | Development Status :: 2 - Pre-Alpha |
| Classifiers: | Programming Language :: Python |
Abstract
This work was started as an effort to better understand the impact of different Python pep-333 WSGI application profiles on server performance. This is still the focus of development. This server is NOT FOR PRODUCTION USE. This server implementation owes a lot to several prior works:
Keep-Alive works for both HTTP/1.0 and HTTP/1.1 clients and is essential for best performance.
The implementation requires Python 2.5, and (currently) linux and the poll system call.
For documentation on using the dispatch mainloop and implementing compatible dispatch targets see asynwsgi.dispatcher and asynwsgi.tcpsocket
For the current server implementation see:
python -m asynwsgi.wsgiservice.server --help
For a minimal async http clients see:
python -m asynwsgi.httpclient oneraw --help python -m asynwsgi.httpclient bulkfetch --help
For profiling, use the --profile option of the server above in conjunction with:
python -m asynwsgi.bench.http_processing --help
For a means to stress test the server on a single host see:
python -m asynwsgi.bench.tool saturate --help python -m asynwsgi.bench.tool bench --help
Both saturate and bench start a single server instance. saturate runs one instance of a http_processing client while bench runs mutliple GET and POST async client processes (http_processing instances with appropriate options) against the same server instance.
For a means to generate and sustain a large number of pending connection attempts with the server - Ie, MORE than the rate at wich the server can accept those connections - see:
python -m asynwsgi.sclients.main --help
And take a look at the C10k site for a detailed explanation of what an sclient is and what you can do with one.
Copyright (c) 2007 Robin Bryce
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Certain aspects of the wsgi spec implementation may be neither complete or correct. Development is currently focused on identifying how performance of async servers is affected by aspects of the wsgi spec.
For Transfer-Encoding:chunks: read, readline etc are NOT SUPPORTED. The only means to process the input is via the __iter__ method. See asynwsgi.wsgiservice.server:wsgi_file_uploader for an example. The yield pattern for __iter__ is also somewhat specialised. It is:
[chunksz, datafirst] [data]* [chunksz, datafirst] [data]* ... [0 '']
This pattern enables the server to deal with chunk boundaries on behalf of your application with out incurring excessive buffering overhead.
The iterator will raise StopIteration after it has yielded the terminating chunk. The future plan is to incorporate trailer headers into this yield pattern but presently any trailer headers are silently droped on the floor (this is actualy RFC 2616 compliant although not very friendly).
Your application iterable is GUARANTEED only to be resumed if input.next() has some data ready (either [chunksz, datafirst] or some/all of [data]*). If on a subsequent iteration the server detects EAGAIN/EWOULDBLOCK then input.next() will return wsgi.input_sentinel. If your application sees this value it should simply yield it back to the server. So the simplest idiom is:
uploaded = cStringIO.StringIO()
content_length = 0
for v in iter(environ['wsgi.input']):
if d is environ['wsgi.input_sentinel']):
yield d
continue
if not isinstance(d, str):
chunksz, d = d
content_length += chunksz
uploaded.write(d)
assert len(uploaded.getvalue()) == content_length
Note: wsgiservice.server has an example application interable that handles POST with transfercoding:chunks and you can test this using:
python -m asynwsg.bench.http_processing --synthesize-post=NCHUNKS\ --chunksz=NBYTES http://localhost:8080/uploader/
POST suport where Transfer-Encoding header is absent or is set to 'none' At present the server collects all the data into a cStringIO.StringIO instance and does not invoke the application until all input has been collected. (AND this is not particularly well tested at present)