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.
