谁有空帮我用linux测试一下这段代码

yulihua49

通过网络读写占用了时间，调用accept的机会少了。本机的时候读写快，体现不出来。
hellioncu 发表于 2011-07-27 11:17

     对。一个线程排队等网络。
所以，1.多线程。2.单独的线程accept，就像我的例子。通常是主线程，还可以兼顾干点check timeout等等的事。
实践证明这对提高吞吐量和可靠性非常有效。

我那个程序需要为每个客户端定义context，内容自定，必须要有的是socket，event（事件状态），callback（事件执行），status（自身状态）。
events->data->ptr 指向每个客户端的context。所有context组成一个池。

redor

代码我改了一下就好了 我把listen的backlog 改成1024就好了 这个值不能是65536 65535都可以。。。 不知道是不是系统bug。。。。。。

yulihua49

代码我改了一下就好了 我把listen的backlog 改成1024就好了 这个值不能是65536 65535都可以。。。 不知道是 ...
redor 发表于 2011-07-27 12:20

    单线程依然不能发挥多核的能力。

redor

单线程反而能正常 多线程就出状况。。。。 而且还有明显的延迟问题。

yulihua49

单线程反而能正常 多线程就出状况。。。。 而且还有明显的延迟问题。
redor 发表于 2011-07-28 19:02

    你没弄对？我的都很好。

redor

我多线程下 压力测试的时候 干活的线程基本都是CPU用光。。。。 我现在还不确定是不是CPU太高导致IO受影响

yulihua49

我多线程下 压力测试的时候 干活的线程基本都是CPU用光。。。。 我现在还不确定是不是CPU太高导致IO受影响
redor 发表于 2011-07-30 14:09

    很好啊，这是我追求的境界。通常线程锁使得cpu用不光。
我们在有连接池管理的时候，由于线程锁的问题，CPU最高只能90%。100%是我们梦寐以求的。
cpu用光说明系统处理能力达到极限。等待时间就是不能再短的等待时间了。如果达不到要求，增加核数吧，或用多台服务器处理。
最怕的就是响应时间长，CPU又空闲，你都不知道增加核是否能奏效。

redor

我现在的问题是epoll_wait反应不过来 很多时候会顿住 几十毫秒。。。 实际上我是有可写的事件的。
另外还发现一个问题是 epoll_wait经常被信号中断。。。。。

yulihua49

我现在的问题是epoll_wait反应不过来 很多时候会顿住 几十毫秒。。。 实际上我是有可写的事件的。
另外还发 ...
redor 发表于 2011-08-02 11:40

顿住 几十毫秒?CPU忙不过来？
没线程守候了，还是守了几十毫秒？

redor

这代码搞得我最近头大死了 感觉遭遇RP问题。。。。
现在的问题是server端接收数据没问题了 server端发出来的数据 client没法收到 epoll那都没响应了。