boost asio coroutine连接池

lims_xlh

在采用asio coroutine多线程网络的时候，每个线程绑定到一个io_service,这样的话怎么在不加锁的情况下使用socket连接池来处理连接复用

yulihua49

lims_xlh 发表于 2015-04-09 17:49
在采用asio coroutine多线程网络的时候，每个线程绑定到一个io_service,这样的话怎么在不加锁的情况下使用s ...

我这两天正做这个，快成了，还在调试。
三维的连接池管理。

一个服务器多个连接。
多个服务器组成cluster。有负载均衡和容错功能。
多个cluster构成一个路由系统，根据需求选择路由（应用路由，或称交易路由）。

AIO coroutine 线程池  epoll  都用上了，看来还工作的不错，就是容错还有些问题，过几天就可能调好了。
不过，任何一个server并不绑定线程。客户端、线程、协程、服务器的连接，谁也没绑定谁，乱跳。线程锁是少不了的，不过设计好了，它并不影响性能。
压力测试，看日志，各种资源的随机组合，眼花缭乱的。

其实线程锁并不是那么可怕。影响性能的首要因素是写日志。其次是epoll的激活过程（单个epfd每秒最多激活15万次，与核和线程数无关）。这俩其实也是锁，内部的，你管不了。其它锁对性能对影响可忽略不计。

没用boost，担心其性能。
用的ucontext，担心将来系统不支持。

将来有空研究下 setjmp/longjmp 的实现方法。

lims_xlh

回复 2# yulihua49
但是对于异步 coroutine来说锁的开销是比较大的，因为异步是用尽可能少的线程去做尽可能多的事情，有锁等待就意味着它处理的其他的事情
精力变少了，会很影响性能吧，我现在的做法是每个线程内维护一个连接队列，每次来了client从连接里面拿一个，不知道有没有别的成熟的方案


   

yulihua49

lims_xlh 发表于 2015-04-10 10:13
回复 2# yulihua49
但是对于异步 coroutine来说锁的开销是比较大的，因为异步是用尽可能少的线程去做尽可 ...

总共就是一个context池，accept，来了个连接，就分配给它一个。然后丢到epoll队列里。此后这个context就是独享的了，操作这个context不需要锁。前提是epoll没有惊群，就是没有把一个context分配给多个线程。
其他线程都在epoll_wait。抓到event，取出context，这时，线程才临时有了context。它没有固定的context。
锁的问题比较复杂，一句两句说不清，总之要避免“无谓”的等待。
我一直主张采用一种成熟的中间件，自己写这些程序要面临很多的问题。

yulihua49

lims_xlh 发表于 2015-04-10 10:13
回复 2# yulihua49
但是对于异步 coroutine来说锁的开销是比较大的，因为异步是用尽可能少的线程去做尽可 ...

每个线程内维护一个连接队列，每次来了client从连接里面拿一个-------这个client绑在这个线程了？不利于负载均衡。
还是不要绑定的好，那个线程有空就哪个线程干。这样平均响应时间才快。
给你一种评估方法：最长响应时间/平均响应时间，越小越好，你可以把几个方案评测一下。

lims_xlh

回复 4# yulihua49
我上面可能没说清楚：
我现在的情况是这样的，我使用的boost asio 加coroutine，
boost asio 用IOCP封装了epoll ，我现在有一个线程，accept一个客户端，然后给客户端分配一个socket（连接后端服务的socket）去连接后端服务做业务，
在这个socket上面可能会读写数据，但是iocp是等到读写事件完成了之后就回调完成函数，在等待读写时间的过程中courotine是可以让这个线程去accept
新的客户端的，这样这个新的客户端可能也需要一个socket去处理后端业务。

根据上面情况每个线程就会操作多个client和 socket，我怎么更好的复用这个线程使用的所有的socket呢？

   

yulihua49

回复 6# lims_xlh

一个主线程accept，得到客户socket后分配它context。然后抛给epoll。继续accept。
一群工作线程epoll_wait,谁捡到event算谁的。这样，所有的工作线程抢所有的context。


   

yulihua49

yulihua49 发表于 2015-04-09 20:30
我这两天正做这个，快成了，还在调试。
三维的连接池管理。

容错测试今天基本通过。

yulihua49

[quote]BetonArmEE 发表于 2015-04-13 18:23
牛逼。我现在整天都在写业务，没时间搞技术了，唉[/quote
嗯。
平台需要专人搞。做业务哪有功夫弄平台？一个东西要弄好几个月，只用于一个项目未免成本过高，再说一般情况也不允许花这么大代价搞基础设施。
另一方面，如果你的平台没有集成尽可能多的精英技术，也就失去了存在价值。
都是常规技术，人家用不着你，自己都解决了。

不过我的体会，倒不是这些技术有多精英，而是在把它们组合在一起时，太多的不确定性。组合成稳定的大杂烩，太困难了。

G5是你的？我原想结合G5来做负载均衡。现在看来不用了。楼上那个架构，包含了负载均衡／容错层，够用了。
对G5依然很讚赏。

容错还有不满意，keepalive有时还是需要较长的时间才能确认一个资源失效。