4 ms·
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
by zhenjl 12y ago
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.
- itchyouch 12y agoAre 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/ 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.
- zhenjl 12y agolo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 Mac OS Yosemite..
- eternalban 12y ago> 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()) // … }
- zhenjl 12y agoI ran with GOMAXPROCS=2 on the command line. The post showed the actual commands that I used in each case.
- eternalban 12y agoAh, 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.