epoll 与连接池

[nezhazheng]

像数据库连接池或者其他涉及到网络通信的连接池的存在的目的，是复用已创建的网络连接，减少重复创建连接的开销，提升性能。这种连接池大多是用传统的阻塞IO创建的连接。

如果client端是使用epoll模型的IO，是否就可以不用传统的连接池，创建大量IO连接的方式，而达到一个epoll连接（加上业务线程池的方式）”以一挡百“的效果呢？

[skybr]

可以, 不过也得用的数据库驱动支持, 比如mysql提供的client library就不支持, 而mariadb和postgresql的就暴露了事件接听的接口.

[skybr]

事件<del>接</del>监听

[miaoever]

我觉得这是两个层次的概念呀，要先建立连接，再进行 I/O 操作吧（访问数据库或者扔到 epoll 的 eventloop 里去)。连接池的作用主要是用于前者吧，所以连接池和非阻塞 IO 模型(epoll/kqueue...)不冲突的。

[reusFork]

epoll是用来通知连接的IO事件的，用或者不用，连接都还是连接，没有什么epoll连接。连接池和epoll没有冲突

[tonyluj]

用了epoll虽然可以同时handle大量的请求，但是底层的实现貌似还是阻塞的，除非能实现非阻塞的，否则性能没有太大的提升。

epoll模型主要还是用在web server上吧，select/poll不能同时handle这么多的fd，并且一旦多了，轮寻的时间复杂度就越大，epoll采用了callback。但是虽然Handle了这么多，但是后面的IO一阻塞，照样也是要等，除非后面的IO是非阻塞的或者多线程的。

[est]

没搞懂LZ想说什么。。。。。epoll 和连接池不是一个层面的事情怎么拿来对比。。。。。epoll 是一个事件触发机制，连接池是节省TCP握手和session初始化的时间，怎么比？莫非想在单个TCP里做epoll 达到复用连接的目的？

[cloveryume]

楼主的意思是避免一个连接一个线程？epoll用在client端不一定适合，引入异步回调，就要有相应的同步机制，可能还要有队列。

[nezhazheng]

@miaoever
@reusFork
@tonyluj
@est
@cloveryume

大概理解了，也就是说在客户端，一个epoll连接要想比一个阻塞IO的连接池性能高，除非服务端是大量的慢速处理，是这样吧，当服务端处理速度非常快，并且大并发的情况下连接池是必须得。