http请求的socket信息必然需要存储,直到这个http请求结束。upstream的长连接是非阻塞的,一个http请求通过upstream发送给后端的服务器,如果服务器没有响应,那么这个upstrem会处理其他http请求。感觉并不需要修改你们的后端服务器,除非这个后端服务器只支持一个连接接入。
ngx-lua的cosocket功能可以完全替换upstream的功能,所以能写lua尽量写lua,写upstream就要用c了。
在 2012年10月30日星期二UTC+8上午10时28分06秒,珠珠写道:
开始我的设想是:整个webserver部分已有一条tcp连接到upstream,接着看到nginx是多进程的,设想每个进程1条tcp连接到upstream,不过确实实现起来可能得不偿失。
> keepalive的长连接某一时刻也只能给一个前端http用户使用;不过适应这个构架很好
>
这里我的意思是后台 upstream的那个长连接,我看ngx_http_upstream_keepalive_module 是用连接池的,如果只用一条upstream的长连接,势必要保存前端http连接socket,并将该信息关联,等upstream返回再找到前端http连接socket做回应。从效率上看,连接池也是十分高效的,所以我说改动后台服务器代码适应了这个也是很不错的。
以上是我现在的想法,也有可能对nginx upstream keepalive理解错误。