sogou / workflow

C++ Parallel Computing and Asynchronous Networking Framework

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

websocket并发问题咨询

Detxie opened this issue · comments

问题描述

  1. 我在项目中使用workflow-websocket-client,wfrest。
  2. 当ws-client并发数增加到100+时,整个软件服务开始出现超时,延时现象。wfrest http超时(curl http://127.0.0.1) , ws-client接收也变得很慢。

服务器环境

  1. 24个物理核,48个逻辑核
  2. 在服务初始化时设置了poller线程为48,handle线程为24
  3. 有一个软件服务A,服务A每次启动32个ws-client连接。
  4. 当我启动3个A进程时,一共有96个ws-client连接,这时候是OK的,每个A进程http服务,ws都可用。当启动第四个A进程时,其中一个A进程开始出现http服务超时。

一些疑问

  1. 我在测试12个逻辑核时(此时配置Poller线程为12,这个服务器也只有12核),开启一个A进程是没问题的(32个ws-client连接)。
  2. 为什么当逻辑核为48时,4个A进程就出现超时问题。
  3. 按照我的理解来说,对于一个进程,我设置poller=12,32路ws-client测试可以。那我把4个进程放到一个48核的服务器上是不是应该也可以?测试不可以后,设置了每个进程poller=48,还是不可以,会出现超时问题。
    3.1 A(12) A(12) A(12) A(12)
    3.2 A(48) A(48) A(48) A(48)
  4. 我的理解应该是有问题,能给一些后续排查问题的思路么。

你好,感谢详细的测试数据。想确认几个问题:

  1. 你当前的CPU跑满了吗?如果CPU没跑满,那么就不是因为核数的问题而导致的第四个进程A启动之后的超时,可能是因为别的限制,比如网卡满了之类的。
  2. 超时拿到的timeout reason是什么呢?
  3. 可以尝试改成等价的单进程,但这个只是随便猜测看看是否有其他超出预期的问题。因为根据websocket client的实现,你开4个进程 * 48个poller,其实等价于1个进程 * 48 * 4个poller,不过当然咱们现在核数只有48所以你也不用开那么多,假设96个就够了。如果1个进程*96个poller线程也超时,再看看是不是负载或者网卡的问题;如果1个进程没有超时,吞吐大约可以达到12核的情况的4倍,我们再看看是什么原因。

@Detxie Hi,这个有什么进展么?如果有新发现的话欢迎分享哈~