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 选项；此选项将产生类似的结果，但其方式更为简便。