uWSGI 1.9.12¶
更新日志[20130605]
错误修复¶
- 卸载缓存写入将会反悔正确的状态码，而不是202
- 你现在可以设置TMPDIR环境变量，来控制临时文件的路径了 (这为那些没有/tmp路径控制权的用户修复了一个老问题)
- 修复amqp imperial监控器上的一个编译错误
- 当cron被报告到统计信息服务器的时候，会正确的被转义
- 修复上传大文件的时候fastcgi解析器的极端情况
- 修复对最新的cygwin的支持
新特性¶
卸载响应¶
看看下面的WSGI应用：
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['u' * 100000000]
它将生成大约100兆数据。worker花费在该请求上的98%的时间都是数据传输。由于整个响应是紧随请求之后的，因此，我们可以卸载该数据写入到一个线程里，然后立即释放worker (这样，它就可以处理新的请求了)。
100兆很大，但甚至是1MB都可以引发十几个poll()/write()系统调用，这会阻塞你的worker不少毫秒
多亏了在1.9.11中添加的“内存卸载”功能，实现它变得非常简单。
通过 uWSGI转换 实现卸载
[uwsgi]
socket = :3031
wsgi-file = myapp.py
; offload all of the application writes
route-run = offload:
默认情况下，会将响应缓存至内存，直到它大小为1MB为止。之后，将会将其缓存至磁盘，接着卸载引擎会使用sendfile()。
你可以设置磁盘缓存后的限制 (以字节为单位)，传递一个参数给offload:
[uwsgi]
socket = :3031
wsgi-file = myapp.py
; offload all of the application writes (buffer to disk after 1k)
route-run = offload:1024
“offload”必须是该恋中的最后一个转换
[uwsgi]
socket = :3031
wsgi-file = myapp.py
; gzip the response
route-run = gzip:
; offload all of the application writes (buffer to disk after 1k)
route-run = offload:1024
JWSGI和JVM改进¶
已扩展了JVM插件，来支持更多的扶助对象 (例如ArrayList)，而JWSGI现在可以被当成一个低级别的层次使用，来天津队更多基于JVM语言的支持。
JRuby集成是这类应用的第一个尝试。我们刚刚发布了一个JWSGI到Rack适配器，允许你在JRUBY之上适配运行 Ruby/Rack应用：
https://github.com/unbit/jwsgi-rack
关于Jython的一个类似的方法正在开发中
–touch-signal¶
添加了一个新的touch选项，允许当touch一个文件的时候，引发一个uwsgi信号：
[uwsgi]
...
; raise signal 17 on /tmp/foobar modifications
touch-signal = /tmp/foobar 17
...
memcached路由改进¶
你现在可以把响应存储到memcached中了 (正如你已经可以用uWSGI缓存做到的那样)
[uwsgi]
...
route = ^/cacheme memcachedstore:addr=127.0.0.1:11211,key=${REQUEST_URI}
route = ^/cacheme2 memcachedstore:addr=192.168.0.1:11211,key=${REQUEST_URI}foobar
...
显然，你也可以获取它们
[uwsgi]
...
route-run = memcached:addr=127.0.0.1:11211,key=${REQUEST_URI}
...
当前，会在默认配置文件中内置memcached路由器
新的redis路由器¶
基于memcached路由器，添加了一个redis路由器。它的工作方式相同：
[uwsgi]
...
route = ^/cacheme redisstore:addr=127.0.0.1:6379,key=${REQUEST_URI}
route = ^/cacheme2 redisstore:addr=192.168.0.1:6379,key=${REQUEST_URI}foobar
...
... 以及获取值
[uwsgi]
...
route-run = redis:addr=127.0.0.1:6379,key=${REQUEST_URI}
...
默认内置redis路由器
“hash”路由器¶
这个特别的路由动作允许你哈希一个字符串，并从列表中返回一个值 (由哈希键索引)。
看看下面的列表：
127.0.0.1:11211
192.168.0.1:11222
192.168.0.2:22122
192.168.0.4:11321
以及一个字符串：
/foobar
我们使用djb33x算法来对字符串/foobar进行哈希，然后应用模4 (项列表的大小) 到结果中。
结果为”1”，所以，将会获得列表中的第二个项 (显然，索引是从零开始的)。
你认出这个模式了吗？
是的，它是一种标准的将项分布到多个服务器上的方式 (例如，memcached客户端用它已经有很长的一段时间了)。
这个哈希路由器公开了这个系统，允许你分布项到你的redis/memcached服务器上，或者做其他有趣的事。
这是redis的用法示例：
[uwsgi]
...
; hash the list of servers and return the value in the MYNODE var
route = ^/cacheme_as/(.*) hash:items=127.0.0.1:11211;192.168.0.1:11222;192.168.0.2:22122;192.168.0.4:11321,key=$1,var=MYNODE
; log the result
route = ^/cacheme_as/(.*) log:${MYNODE} is the choosen memcached server !!!
; use MYNODE as the server address
route = ^/cacheme_as/(.*) memcached:addr=${MYNODE},key=$1
...
你甚至可以从uWSGI支持的那些哈希算法中选择使用的算法
[uwsgi]
...
; hash the list of servers with murmur2 and return the value in the MYNODE var
route = ^/cacheme_as/(.*) hash:algo=murmur2,items=127.0.0.1:11211;192.168.0.1:11222;192.168.0.2:22122;192.168.0.4:11321,key=$1,var=MYNODE
; log the result
route = ^/cacheme_as/(.*) log:${MYNODE} is the choosen memcached server !!!
; use MYNODE as the server address
route = ^/cacheme_as/(.*) memcached:addr=${MYNODE},key=$1
...
默认会编译该router_hash插件