目前部门网络组件bug 较多不稳定，准备自己改一改，所以现在想一想应该怎么处理！！
目前部门业务主要就是：
1、网络I/O
2、CPU在内存中的计算
so：瓶颈应该是在网络I/O中，毕竟不是CPU密集型，所有的数据都在内存中处理
多线程：要防止频繁的CPU切换，上下文的切换又涉及程序计数器、堆栈指针和程序状态字等一系列的寄存器置换、程序堆栈重置甚至是 CPU 高速缓存、TLB 的切换 所以多线程绑定到具体CPU 比较好
多进程：相比多线程，进程间通讯耗CPU，所以进程间 地址空间分离是有坏处但是也有好处！！好处就是稳定 进程间干扰少，不像单进程多线程一样，一个线程coredump 导致了进程退出；
当然多机分布式的时候，进程比线程好，还有一点 线程相比进程 切换调度 创建销毁都要快，CPU 利用率高、占用内存要少
所以如果遇到CPU密集型->计算量大-->cpu切换多，很可能需要多线程！！但是多线程调试有点坑。
考虑到一个http代理缓存的功能-----> CPU 瓶颈应该在网络io 不应该在计算，毕竟计算不多，也不会像web服务器，需要大量创建销毁process来处理，所以从这样看多进程比较好，
同时网络设备要求稳定，多线程一个线程挂掉了可能会导致整个进程退出！！ 有可能涉及到http报文的pkt收发 pkt处理，两者相关性强，但是这两个都在一个进程中处理就行，所以单进程可以解决问题，不一定非要多线程；
结论也就是：多进程
说到I/O就肯定涉及到epoll/poll/select 对于其分析请参考之前文章:epoll分析以及 epoll/select效率 等；
根据业务量：准备选择epoll了；
那么问题来了？
reactor模型 ？水平边沿触发的选择？
选择了多进程所以准备多reactor了！！
那么epoll是水平还是边沿？？
业务主要是：http代理分析报文转发，一般都是网关，流量比较大；ET模式相比LT 被唤醒的次数要少，ET编程难度要高，
如果流量一直来，那是不是有可能ET一直都在rcv数据，导致其余的fd饿死等情况？？这种情况只能在编程时慎重处理了！！！
所以EPOLL-ET了
原文：https://www.cnblogs.com/codestack/p/14519863.html