May 28, 2015
On Thursday, 28 May 2015 at 02:00:57 UTC, zhmt wrote:
> I think it is not problem of gc, it is my fault:
> The operations is serialized:
> clent send  -> server recv  -> server send  -> client recv,
> so if one operation takes too long time, the throughput will definitely fall down.
>
> I cant explain why it so fast when buffer is big enough, and so low when buffer is smaller than data size.


I found the root of the problem :

tcp_nodelay, it is default false. After i modify it to true, the program runs exactly as what I expect.

sorry, it is a low level error.


the throughput is steady now: if buffer size is set to 1, throughput is about 20K response/second; when buffer size is big enough ,the throughput is about 60K response/second.

It looks like resonable.
May 28, 2015
Thanks for all help.
May 28, 2015
On 05/28/2015 03:13 AM, zhmt wrote:
> Thanks for all help.

Thank you for debugging and reporting. :) I am sure this will be helpful to many others.

Ali

May 28, 2015
On Thursday, 28 May 2015 at 10:11:38 UTC, zhmt wrote:
> On Thursday, 28 May 2015 at 02:00:57 UTC, zhmt wrote:

> the throughput is steady now: if buffer size is set to 1, throughput is about 20K response/second; when buffer size is big enough ,the throughput is about 60K response/second.

checkout msgpack-rpc-d, i remember handling around 300k req/s
1 2 3
Next ›   Last »