Hacker News Reader

Comment by zhenjl | Hacker News Reader

When I ran this I gave the server and client 2 cores each. Neither were maxing out the cores.

At about 856K MPS (sent + received) @ 1024 bytes/msg, that's less than 1 GBps. So I can't imagine it being io(net) bound either.

So inconclusive...unfortunately. Need to profile a bit more to know.

Edit: Tho this is TCP based so it's possible that it's netio bound given the protocol overhead. At this message rate, each packet is almost guaranteed to be full size. So we are doing about 600K pps, approximately.

View on HN

Are you passing messages on the same host? When doing message passing between processes on the same machine, memory mapping and shared memory will be your friends. Check this architecture out for intra-host message passing: https://lmax-exchange.github.io/disruptor/

If you are doing tcp over loopback, the MTU is 64K, IIRC. You should be able to pack more messages per packet. Since you aren't CPU bound, you are probably memory bound.

Also if you on a non-kernelbypass accelerated host, wire-to-application memory takes about 10 micros, so wire-to-memory-to-wire will probably land somewhere around 20 microseconds.

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

Mac OS Yosemite..

> When I ran this I gave the server and client 2 cores each. Neither were maxing out the cores.

grep for GOMAXPROCS didn't turn up anything so not sure what you mean by that. This may help with core utilization.

   func init() {
       // 
       runtime.GOMAXPROCS(runtime.NumCPU())
       // …
   }

I ran with GOMAXPROCS=2 on the command line. The post showed the actual commands that I used in each case.

Ah, missed that. In any event, that sets the number of Go Processors per Go runtime. It has no bearing on the number of "cores" utilized.

Reply on news.ycombinator.com