[问题] 多执行绪服务器设计问题

楼主: klsdf (静雨澪)   2019-03-14 22:53:42
版上各位先进好:
小弟我目前在设计多执行绪的服务器上遇到效能瓶颈,
底层的Socket Server是用Boost::Asio,
单纯用single io_service & multiple thread的架构处理效能还不错,
但目前系统上都会需要封包指令是要将某个index要对应到某个session,
所以只好在accept时把index跟session存入到map中,这时就需要使用lock去做保护,
因为加了这个lock导致在一秒内如果是上万的连线数要aceept延迟就会提高,
后面开始run的过程中因为我使用的是shared_mutex,
所以对map纯读(shared_lock)感觉效能还可以。
如果是单纯读写分离的Queue还可以用boost::lockfree去处理,
但遇到真的架构上就需要有一个map,这种情况就不知道怎么优化它,
想问版上的各位先进有什么设计方向可供我参考,谢谢。
作者: tinlans ( )   2019-03-15 02:30:00
白说这问题打成英文上 stackoverflow 问应该会比较好坦白说目前可以知道的资讯有点少,也许你目前这层可以复制 N 个docker containers 去跑起来,然后最前端再挡个类似负载平衡的东西,譬如根据 index % N 的值来转发封包给对应的container 处理这个 request。这种解法比较偏向架构解,考量将来 scalability 的话你早晚要做类似的工。如果你只打算先集中在程式解,那试试看起多个 io_context 有没有什么用吧。io_service 在新版 boost 已经 deprecated 了。简单讲的话目的都是先增加你程式的入口数,然后把原本因为 lock 变成瓶颈的单一大资料块拆分成多个。
作者: easyman (oops)   2019-03-15 00:27:00
vector 存 index + session, 就不用lock ?
作者: Schottky (顺风相送)   2019-03-14 23:04:00
问题在于你为什么会设计成一秒需要 accept 上万次吧
作者: sarafciel (Cattuz)   2019-03-15 14:32:00
int64_t你也用不完呀 实务上你抓个可以涵盖峰值的大小配就好了 而且vector要锁最起码可以个别锁呀
作者: ketrobo (猫萝卜)   2019-03-16 07:29:00
每一条连线有平均与最大的耗用资源量,同时估计一下response time/CPU时间,找出一台机器的服务上限,对应的session数量一次配置完,连线对应固定的索引值就不用map了
作者: steve1012 (steve)   2019-03-17 01:02:00
写个load balancer
作者: LiloHuang (十年一刻)   2019-03-17 19:58:00
SO_REUSEPORT https://goo.gl/4rxJfr 参考看看若非得查表可考虑使用 tbb::concurrent_unordered_map

Links booklink

Contact Us: admin [ a t ] ucptt.com