Home

zhangyiqun

Thoughts, stories and ideas.

2014年以前 About Feed

31 Jan 2010
关于在线代理的思考及优化思路

凸墙自从上线就没怎么管过,最近发现网页时有打不开的现象,因为购置的VPS并非独立服务器所以我确实仔细分析了内核参数,nginx配置,fastcgi并没有发现异常,但是可以断定问题肯定是出在fastcgi处理连接上,因为每次重启fastcgi后页面又会恢复往常的访问速度了。

晚上向超群大牛请教了下这个问题,他看过代码后曰:

fastcgi是进程阻塞的模型,而在线的访问(web proxy)非常消耗进程。

那么当我用在线代理去请求一个页面,fastcgi将会一直阻塞直到一个页面读完,这个等待时间在网络I/O中所占时间太长。有意思的是Nginx 的核心是网络 I/O 非阻塞。所以从nginx的角度来看fastcgi 永远是阻塞的,从fastcgi的角度看,fastcgi 的另一边永远是阻塞。那么纵然我nginx能接受再多的连接,但最后还要卡在fastcgi上。

在google里找了一圈发现的都是在nginx或者apache与fastcgi的超时时间,却没发现fastcgi自身的设置能够解决模型本身弊端(或许说不上)的方法。

在nginx中

以下两个选项用于防止网络阻塞

tcp_nopush on;

tcp_nodelay on;

在apache中

appConnTimeoutn(0 秒)

等待到 FastCGI 应用程序的连接完成的秒数,0 表明使用阻塞 connect()。如果超时到期,则产生 SERVER_ERROR。对于非零值,这表示 select() 中用于写入由非阻塞 connect() 返回的文件描述符的时间量。在许多平台上,非阻塞 connect() 很容易产生问题。另见 -idle-timeout 选项;此选项将产生类似的结果,但其方式更为简便。


zhangyiqun

scribble

2014年以前 About Feed