呃。。。笔误： s/都有自己的 thread/都有自己的 stack/

使用多线程拼并发的一个缺点是每个线程都有自己的 thread，呵呵，因此线程数一大，就得用较小的 stack size，于是程序逻辑会受制于很小的 stack size，否则 10K 并发很容易用尽所有的 RAM，因此函数递归啥的，就得悠着点儿用了，呵呵。我昨儿在用 1 万并发去压 tokyotyrant 服务器时，就不得不将 ttserver 使用的 stack size 调小到 500 KB（用 100KB 的话，ttserver 就直接 segfault 栈溢出了，呵呵），这样让它起 3000 个 pthread 就差不多可以扛 10k 并发了。默认的 MB 级的 stack size 一下就把我的本本上的 RAM 都用得差不多了，哈哈，pthread 都无法成功创建。

详情见这篇著名的 C10K 文章中的讨论： http://www.kegel.com/c10k.html 当然，也有一些哥们抨击 multi-thread 在高并发场合的严重的性能开销，是因为缺乏真正靠谱的 multi-thread 实现所导致的，关于此问题在那篇 c10k 中亦有讨论。。。呵呵。

我们发现，对于 nginx + php farm 的并发性能影响最大的经常是，当 php 发起到 DB 或者 memcached 或者后端 HTTP service 时，当前 php 进程是阻塞的。

因此我们打算试试让 php 进程需要发起二级 IO 请求时，直接由 nginx 的 subrequest 来代理之，这样，php 端的 IO 便可以与 nginx 的性能极好的 event model 融为一体，从而提升单机整体的并发能力。（这对于 Perl/Python/Ruby/Haskell/V8 等其他的以 fastcgi 形式挂在 nginx 后面的 web 应用亦是适用的。）

因此我们需要借用 fastcgi 协议去支持 fastcgi 后端直接发起 nginx subreqest，并传递 subrequest 完成后需要打开的“continuation 对象”，并结果和控制权重新交回指定的 fastcgi 后端入口。