网络服务器与池

网络服务器:http://www.ibm.com/developerworks/cn/linux/l-cn-edntwk/

“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。

  池这种东西看起来似乎很高深,其实在服务器端一般也都这么用,不去细细想也就没察觉了.通过减少创建和销毁的频率而降低系统开销

select与epollhttp://blog.csdn.net/tfengmao/article/details/8549664
关于select, epoll虽然平时经常用,但也没怎么关注它的实现,说起来挺惭愧的

1. select的实的特点

Select 实现具有如下特点：

1）每次调用select系统调用，都需要从用户空间拷贝数据到内核空间；
2）对于每一个fd（用户可以传送一批fd）调用其对应的设备的poll函数，对于socket来说，就调用tcp_poll函数；并收集设备是否有事件发生；

3）轮询了所有fd后，若没有事件发生，该函数就挂起，直到通知有事件发生，或者超时。

对于3）中，若扫描所有fd后，没有事件发生，该调用线程会挂起，那在什么时候，由谁唤醒该线程呢？这里就需要仔细考察下poll函数了。Poll函数将会将调用的线程挂在设备的对待队列中，当设备有事件发生的时候，就会唤醒等待队列中的线程。这里，就会唤醒调用select系统调用的线程。

从上面可以看出，若用select来实现一个事件循环的话，每次循环都会将fd从用户空间复制到内核空间，并且轮询每一个fd对应的设备状态；这看起来确实不明智。



2. epoll实现的特点

从用户空间向内核空间拷贝数据，和轮询设备都是费时操作，对于fd量很多的情况下，select就明显吃力了。Epoll就在这时候诞生了，epoll的实现克服了select的在多fd情况下表现的缺陷；基本原则是采用空间换时间的策略。

1）Epoll将每一个fd所需的数据保存在内核，而不是每次系统调用都需要从用户空间复制数据到内核，只是在fd首次注册的时候复制到内核。这样内核需要空间存储fd所需的数据。

2）epoll摈弃轮询设备的做法，而是在监视的设备等待队列中添加一个等待项。

3）当设备就绪后，等待项中的回调函数会调用。该回调函数将设备事件负责到一个链表中，并且唤醒调用epoll_wait的线程。

从epoll的实现来看，采用空间换时间的策略，去掉了重复从用户空间向内核空间复制数据的操作；采用回调机制，避免了轮询设备。从而epoll在大量fd的情况下，性能明显优于select。