我也同意event loop + thread pool的做法，
epoll + 多线程 + 多进程部署 效率真的不错。
先用select接口(poll/epoll,kq,iocp)接受请求，这样可以保证并发，在这个环节他只管收，不处理业务，把FD放到一个buffer(一个q里面)，然后业务处理模型对接线程池。可以使复杂业务处理上的负担被分担。select+线程池，这样兼顾了并发（牺牲了一点性能），又保证了因为逻辑代码的简洁性。如果选择完全异步的方式，你就要在业务处理里面使用完全的异步API，至少很多数据库驱动，缓存驱动等等你需要用的到技术都没有提供异步API，很多业务要保障流程的正确是需要同步操作的，而且业务如果全部使用异步API，各种不明确回调和闭包导致内存暴栈的危险上升(我想各位应该被nodejs折磨过吧)，对开发人员思考方式和技术实力都有较高的要求。一个部门里面有两个了解epoll就算技术非常NB的核心部门了吧，假若有能正确驾驭epoll，了解各种触发方式，状态机，特别是要能正确读写完整的信息，而没有造成大量的CLOSE_WAIT，是特别特别不易的。
我曾在tornado上面搭建过一个线程池。原型参见：
nikoloss/iceworld · GitHub
虽然不算最完美的解决方案，但是也在工作中省去了很多烦恼。他的效率虽没有原生tornado高，但是非常适合多人合作(尽管如此效率还是要暴webpy几条街)。
