用memcached来做例子的确不是很合适，因为memcached中针对请求的处理不存在阻塞的情况。

因此，如果程序作为一个框架来调用第三方的处理模块（无法预知是否阻塞），或者有一些明显耗时的操作，单线程+（I/O）事件驱动明显不是一个好的选择。

架构的优劣嘛，自然是具体情况具体分析。但是说web server使用多线程就是倒退实在是有些偏激了。

1、我也倾向于支持关闭掉keep-alive，原因是可以节省资源（如内存、计时器等），尤其是在有很多one-shot类型的请求时。这点上HAProxy的作者也持类似观点，甚至他都没让HAProxy支持keep-alive。
2、多线程不仅仅是error-prone和锁的问题，在某些场合下，因为上下文切换的缘故，它的性能不一定比单线程高。就拿HTTP来说，一个高效的HTTP协议头解析实现（如nginx）所消耗CPU指令数，远小于线程的上下文切换的代价。既然如此，又何必引进多线程呢？也就说，决定是否使用多线程之前，要明白task的粒度，如果task的消耗已经小于了上下文切换的消耗，那么多线程就不会获得好处。
3、至于要利用多CPU的性能，多个worker进程也可以，不一定非要线程不可。