2017. december 18., hétfő 14:11:34 UTC+1 időpontban Tamás Gulácsi a következőt írta: > > > 2017. december 18., hétfő 13:51:26 UTC+1 időpontban eric.sh...@gmail.com > a következőt írta: >> >> I try to implement a golang tcp server, and I found the concurrency is >> satisfied for me, but the CPU usage is too high(concurrency is 15W+/s, but >> the CPU usage is about 800% in a 24 cores linux machine). At the same time, >> a C++ tcp server is only about 200% usage with a similar concurrency(with >> libevent). >> >> The following code is the demo of golang: >> >> func main() { >> listen, err := net.Listen("tcp", "0.0.0.0:17379") >> if err != nil { >> fmt.Errorf(err.Error()) >> } >> go acceptClient(listen) >> var channel2 = make(chan bool) >> <-channel2} >> >> func acceptClient(listen net.Listener) { >> for { >> sock, err := listen.Accept() >> if err != nil { >> fmt.Errorf(err.Error()) >> } >> tcp := sock.(*net.TCPConn) >> tcp.SetNoDelay(true) >> var channel = make(chan bool, 10) >> >> > why buffered? Who will close it? > > >> go read(channel, sock.(*net.TCPConn)) >> go write(channel, sock.(*net.TCPConn)) >> }} >> >> func read(channel chan bool, sock *net.TCPConn) { >> count := 0 >> for { >> var buf = make([]byte, 1024) >> >> > Why allocate a new slice on every iteration? >
var buf = make([]byte, 1024) n, err := sock.Read(buf) This will be slow: TCP is a streaming protocol, so this Read can read any length between 0 (! yes !) and 1024 bytes. Use buffering (bytes.NewReader) and some kind of message separation (e.g. bufio.Scanner for a line-oriented protocol). Next time please include the full pprof svg, not just the interesting node! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.