原文地址:[url]http://hi.baidu.com/netpet/blog/item/bebc3ba8d671a3b7ca130cf5.html[/url]
学习时间的过程终会有反复,其中也包括一些错误,上午对于前一篇关于epoll的文章进行了增改,下午就觉得有些不妥,重新编辑感觉不太容易剥楼错误,现在有些新的变化在这里重新论述。
上午说的在epoll里面进行耗时任务的时候做一个任务调度器(比如当服务器连接外部资源),这说明我只了解了epoll的一部份,没有充分认识到它的普遍意义的应用,其实对于外部连接epoll可以作为服务器端的任务调度器使用,但是它同样适用于主动式连接的socket,换言之,如果服务器需要连接外部socket资源也同样可以将它连接的道德socket fd加入epoll的监视,这样epoll的调度就更有广泛了,所有需要socklet交互的部分都可以交由epoll,然后他负责监制EPOLLIN和EPOLLOUT两个事件,这两个事件的组合多次利用就可以构成整个服务事件驱动机制,所以我上午说的任务调度其也是多余的。
有人可能想了,那么对于多核服务器不久没有任何优势了么?我的设想是这样的,先在单线程的模型上完成开发,如果想扩展到多核,可以在epoll的下面再次构建一个多线程的任务调度器,也就是将epoll检测到的事件再次保存到一个结构体,用多线程去读取并处理事件,这样不会影响大部分的代码,真正的程序不是直接响应epoll事件,而是在新的任务调度器下面统一处理epoll事件的副本,这样就有epoll主动事件驱动调用变成了异步的,多线程并行执行的模型,但是每个连接同一时间也只有一个线程在处理,现在还没有经过实际测试,不确信对于性能的影响如何。
如果所有实际的处理过程暂用cpu很短那么加上我上面设计的一层任务调度就是多余的,因为所以的问题都会集中体现在网络上,这不是服务器所能解决的,如果网络快到了事件在等待任务,那么这种模型才有可能有较好的表现,所以是否应用还是要看具体的服务内容,事实证明单线程已经处理的足够快了,每秒1万页的处理速度能满足绝大多数的需求,所以就设计而言,关键问题还是要解决瓶颈,而不是将所有想到的好技术都应用上,瓶颈可能还没有得到解决,反而更加浪费cpu资源。
所以我觉决定还是全部以epoll驱动去做这个web架构,毕竟nginx等都有上佳的表现,这样看来做个代理或者反项代理也是很容易的,还可以更加节约资源
看了这么久才算对于nginx等处理模型有了个大致的了解,起初打算更改它的代码,后来发现太麻烦了,所以重新自己架构,走下来发现只要了解思路了具体的技术是很快的,不然看别人的代码太辛苦了
学习时间的过程终会有反复,其中也包括一些错误,上午对于前一篇关于epoll的文章进行了增改,下午就觉得有些不妥,重新编辑感觉不太容易剥楼错误,现在有些新的变化在这里重新论述。
上午说的在epoll里面进行耗时任务的时候做一个任务调度器(比如当服务器连接外部资源),这说明我只了解了epoll的一部份,没有充分认识到它的普遍意义的应用,其实对于外部连接epoll可以作为服务器端的任务调度器使用,但是它同样适用于主动式连接的socket,换言之,如果服务器需要连接外部socket资源也同样可以将它连接的道德socket fd加入epoll的监视,这样epoll的调度就更有广泛了,所有需要socklet交互的部分都可以交由epoll,然后他负责监制EPOLLIN和EPOLLOUT两个事件,这两个事件的组合多次利用就可以构成整个服务事件驱动机制,所以我上午说的任务调度其也是多余的。
有人可能想了,那么对于多核服务器不久没有任何优势了么?我的设想是这样的,先在单线程的模型上完成开发,如果想扩展到多核,可以在epoll的下面再次构建一个多线程的任务调度器,也就是将epoll检测到的事件再次保存到一个结构体,用多线程去读取并处理事件,这样不会影响大部分的代码,真正的程序不是直接响应epoll事件,而是在新的任务调度器下面统一处理epoll事件的副本,这样就有epoll主动事件驱动调用变成了异步的,多线程并行执行的模型,但是每个连接同一时间也只有一个线程在处理,现在还没有经过实际测试,不确信对于性能的影响如何。
如果所有实际的处理过程暂用cpu很短那么加上我上面设计的一层任务调度就是多余的,因为所以的问题都会集中体现在网络上,这不是服务器所能解决的,如果网络快到了事件在等待任务,那么这种模型才有可能有较好的表现,所以是否应用还是要看具体的服务内容,事实证明单线程已经处理的足够快了,每秒1万页的处理速度能满足绝大多数的需求,所以就设计而言,关键问题还是要解决瓶颈,而不是将所有想到的好技术都应用上,瓶颈可能还没有得到解决,反而更加浪费cpu资源。
所以我觉决定还是全部以epoll驱动去做这个web架构,毕竟nginx等都有上佳的表现,这样看来做个代理或者反项代理也是很容易的,还可以更加节约资源
看了这么久才算对于nginx等处理模型有了个大致的了解,起初打算更改它的代码,后来发现太麻烦了,所以重新自己架构,走下来发现只要了解思路了具体的技术是很快的,不然看别人的代码太辛苦了