Websocket: जब संपीड़न चालू हो, तो मेमोरी उपयोग में वृद्धि

पहला कदम शायद आपके आवेदन का एक ढेर और आवंटन प्रोफ़ाइल प्राप्त करने के लिए होगा जो कि पीट का उपयोग कर रहा है।

कृपया पैकेज के नवीनतम संस्करण के साथ प्रोफाइल तैयार करें। पूल फ़्लोट पाठकों के लिए हालिया बदलाव और लिखने में मदद करनी चाहिए।

धन्यवाद दोस्तों,

मैं Centrifugo के अगले संस्करण की प्रतीक्षा कर रहा हूं जिसमें आपका नवीनतम संस्करण शामिल है और फिर आवेदन को प्रोफाइल करेगा और यहां अपलोड करेगा।

आप तब तक इस मुद्दे को बंद कर सकते हैं, लेकिन मुझे उम्मीद है कि आज या कल नवीनतम संस्करण होगा, इसलिए यह आपके ऊपर है।

यहां पर पिपरमेंट डंप है

यह ढेर प्रोफाइल है

@kisielk @garyburd मैंने

https://gist.github.com/joshdvir/091229e3d3e4ade8d73b8cffe86c602b

मैंने उत्पादन नोड से सीपीयू और मेमोरी प्रोफाइल भेजने के लिए @ जोशवीर से पूछा, यहां हमारे पास क्या है:

CPU:

(pprof) top 20 --cum
28.99s of 62.03s total (46.74%)
Dropped 523 nodes (cum <= 0.31s)
Showing top 20 nodes out of 155 (cum >= 8.07s)
      flat  flat%   sum%        cum   cum%
         0     0%     0%     58.68s 94.60%  runtime.goexit
     0.05s 0.081% 0.081%     45.44s 73.25%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessages
     0.16s  0.26%  0.34%     44.23s 71.30%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessage
     0.16s  0.26%   0.6%     44.07s 71.05%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*wsSession).Send
     0.05s 0.081%  0.68%     43.82s 70.64%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage
     0.01s 0.016%  0.69%     21.67s 34.93%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*flateWriteWrapper).Close
     0.03s 0.048%  0.74%     20.19s 32.55%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextWriter
     0.07s  0.11%  0.85%     19.79s 31.90%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover
    17.56s 28.31% 29.16%     17.56s 28.31%  runtime.memclr
     0.04s 0.064% 29.23%     15.46s 24.92%  compress/flate.(*Writer).Reset
     0.03s 0.048% 29.28%     15.42s 24.86%  compress/flate.(*compressor).reset
         0     0% 29.28%     14.40s 23.21%  compress/flate.(*Writer).Flush
         0     0% 29.28%     14.40s 23.21%  compress/flate.(*compressor).syncFlush
     2.62s  4.22% 33.50%     14.01s 22.59%  compress/flate.(*compressor).deflate
     0.01s 0.016% 33.52%     11.05s 17.81%  compress/flate.(*compressor).writeBlock
     0.15s  0.24% 33.76%     11.04s 17.80%  compress/flate.(*huffmanBitWriter).writeBlock
     0.21s  0.34% 34.10%      9.05s 14.59%  runtime.systemstack
     0.06s 0.097% 34.19%      8.87s 14.30%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*messageWriter).flushFrame
     0.07s  0.11% 34.31%      8.81s 14.20%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).write

WriteMessage में बिताए गए अधिकांश सीपीयू:

(pprof) list WriteMessage
Total: 1.03mins
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/conn.go
      50ms     43.82s (flat, cum) 70.64% of Total
         .          .    659:
         .          .    660:// WriteMessage is a helper method for getting a writer using NextWriter,
         .          .    661:// writing the message and closing the writer.
         .          .    662:func (c *Conn) WriteMessage(messageType int, data []byte) error {
         .          .    663:
      50ms       50ms    664:   if c.isServer && (c.newCompressionWriter == nil || !c.enableWriteCompression) {
         .          .    665:
         .          .    666:       // Fast path with no allocations and single frame.
         .          .    667:
         .       20ms    668:       if err := c.prepWrite(messageType); err != nil {
         .          .    669:           return err
         .          .    670:       }
         .          .    671:       mw := messageWriter{c: c, frameType: messageType, pos: maxFrameHeaderSize}
         .       10ms    672:       n := copy(c.writeBuf[mw.pos:], data)
         .          .    673:       mw.pos += n
         .          .    674:       data = data[n:]
         .      1.69s    675:       return mw.flushFrame(true, data)
         .          .    676:   }
         .          .    677:
         .     20.19s    678:   w, err := c.NextWriter(messageType)
         .          .    679:   if err != nil {
         .          .    680:       return err
         .          .    681:   }
         .      190ms    682:   if _, err = w.Write(data); err != nil {
         .          .    683:       return err
         .          .    684:   }
         .     21.67s    685:   return w.Close()
         .          .    686:}

NextWriter:

(pprof) list NextWriter
Total: 1.03mins
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextWriter in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/conn.go
      30ms     20.19s (flat, cum) 32.55% of Total
         .          .    437:// method flushes the complete message to the network.
         .          .    438://
         .          .    439:// There can be at most one open writer on a connection. NextWriter closes the
         .          .    440:// previous writer if the application has not already done so.
         .          .    441:func (c *Conn) NextWriter(messageType int) (io.WriteCloser, error) {
         .       90ms    442:   if err := c.prepWrite(messageType); err != nil {
         .          .    443:       return nil, err
         .          .    444:   }
         .          .    445:
         .          .    446:   mw := &messageWriter{
         .          .    447:       c:         c,
         .          .    448:       frameType: messageType,
      10ms      280ms    449:       pos:       maxFrameHeaderSize,
         .          .    450:   }
         .       10ms    451:   c.writer = mw
         .          .    452:   if c.newCompressionWriter != nil && c.enableWriteCompression && isData(messageType) {
      10ms     19.80s    453:       w := c.newCompressionWriter(c.writer)
         .          .    454:       mw.compress = true
      10ms       10ms    455:       c.writer = w
         .          .    456:   }
         .          .    457:   return c.writer, nil
         .          .    458:}
         .          .    459:
         .          .    460:type messageWriter struct {

compressNoContextTakeover:

(pprof) list compressNoContextTakeover
Total: 1.03mins
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/compression.go
      70ms     19.79s (flat, cum) 31.90% of Total
         .          .     33:   fr.(flate.Resetter).Reset(io.MultiReader(r, strings.NewReader(tail)), nil)
         .          .     34:   return &flateReadWrapper{fr}
         .          .     35:}
         .          .     36:
         .          .     37:func compressNoContextTakeover(w io.WriteCloser) io.WriteCloser {
         .      130ms     38:   tw := &truncWriter{w: w}
      40ms      3.93s     39:   fw, _ := flateWriterPool.Get().(*flate.Writer)
      10ms     15.47s     40:   fw.Reset(tw)
      20ms      260ms     41:   return &flateWriteWrapper{fw: fw, tw: tw}
         .          .     42:}

और अब ढेर प्रोफ़ाइल:

(pprof) top 30 --cum
4794.23MB of 5414.45MB total (88.55%)
Dropped 238 nodes (cum <= 27.07MB)
Showing top 30 nodes out of 46 (cum >= 113.64MB)
      flat  flat%   sum%        cum   cum%
         0     0%     0%  5385.39MB 99.46%  runtime.goexit
         0     0%     0%  4277.82MB 79.01%  sync.(*Pool).Get
         0     0%     0%  4277.82MB 79.01%  sync.(*Pool).getSlow
         0     0%     0%  4182.80MB 77.25%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessages
         0     0%     0%  4181.80MB 77.23%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessage
         0     0%     0%  4181.80MB 77.23%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*wsSession).Send
         0     0%     0%  4181.80MB 77.23%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage
       8MB  0.15%  0.15%  4168.27MB 76.98%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextWriter
      12MB  0.22%  0.37%  4160.27MB 76.84%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover
 3792.80MB 70.05% 70.42%  4148.27MB 76.61%  compress/flate.NewWriter
         0     0% 70.42%  4148.27MB 76.61%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.glob..func1
    0.50MB 0.0092% 70.43%  1156.29MB 21.36%  net/http.(*conn).serve
         0     0% 70.43%   873.42MB 16.13%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*HTTPServer).Logged.func1
         0     0% 70.43%   873.42MB 16.13%  net/http.HandlerFunc.ServeHTTP
         0     0% 70.43%   872.92MB 16.12%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*HTTPServer).WrapShutdown.func1
         0     0% 70.43%   872.92MB 16.12%  net/http.(*ServeMux).ServeHTTP
         0     0% 70.43%   872.92MB 16.12%  net/http.serverHandler.ServeHTTP
         0     0% 70.43%   866.91MB 16.01%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*HTTPServer).RawWebsocketHandler
         0     0% 70.43%   866.91MB 16.01%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*HTTPServer).RawWebsocketHandler-fm
         0     0% 70.43%   404.78MB  7.48%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).ReadMessage
  355.47MB  6.57% 76.99%   355.47MB  6.57%  compress/flate.(*compressor).init
         0     0% 76.99%   320.19MB  5.91%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Upgrader).Upgrade
    0.50MB 0.0092% 77.00%   292.64MB  5.40%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextReader
    1.50MB 0.028% 77.03%   291.64MB  5.39%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.decompressNoContextTakeover
  215.85MB  3.99% 81.02%   216.35MB  4.00%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.newConn
  159.10MB  2.94% 83.96%   159.10MB  2.94%  compress/flate.(*decompressor).Reset
  129.04MB  2.38% 86.34%   129.04MB  2.38%  compress/flate.NewReader
         0     0% 86.34%   129.04MB  2.38%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.glob..func2
  119.46MB  2.21% 88.55%   119.46MB  2.21%  net/http.newBufioWriterSize
         0     0% 88.55%   113.64MB  2.10%  io/ioutil.ReadAll

NextWriter:

(pprof) list WriteMessage
Total: 5.29GB
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/conn.go
         0     4.08GB (flat, cum) 77.23% of Total
         .          .    673:       mw.pos += n
         .          .    674:       data = data[n:]
         .          .    675:       return mw.flushFrame(true, data)
         .          .    676:   }
         .          .    677:
         .     4.07GB    678:   w, err := c.NextWriter(messageType)
         .          .    679:   if err != nil {
         .          .    680:       return err
         .          .    681:   }
         .          .    682:   if _, err = w.Write(data); err != nil {
         .          .    683:       return err
         .          .    684:   }
         .    13.53MB    685:   return w.Close()
         .          .    686:}

compressNoContextTakeover:

(pprof) list compressNoContextTakeover
Total: 5.29GB
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/compression.go
      12MB     4.06GB (flat, cum) 76.84% of Total
         .          .     33:   fr.(flate.Resetter).Reset(io.MultiReader(r, strings.NewReader(tail)), nil)
         .          .     34:   return &flateReadWrapper{fr}
         .          .     35:}
         .          .     36:
         .          .     37:func compressNoContextTakeover(w io.WriteCloser) io.WriteCloser {
      10MB       10MB     38:   tw := &truncWriter{w: w}
         .     4.05GB     39:   fw, _ := flateWriterPool.Get().(*flate.Writer)
         .          .     40:   fw.Reset(tw)
       2MB        2MB     41:   return &flateWriteWrapper{fw: fw, tw: tw}
         .          .     42:}

@FZambia प्रोफ़ाइल जानकारी पोस्ट करने के लिए धन्यवाद।

पूल कितना प्रभावी है यह निर्धारित करने के लिए यहां और यहां काउंटरों को जोड़ा जाना चाहिए। शायद वहाँ एक कोड पथ है जहाँ फ़्लैट लेखक को पूल में नहीं लौटाया जाता है।

संभवतः संबंधित: https://github.com/golang/go/issues/18625

@ y3llowcake इस मुद्दे पर इशारा करने के लिए धन्यवाद।

मैंने गोरिल्ला वेबसैट के लिए टेस्ट केस लिखा है:

type testConn struct {
    conn     *Conn
    messages chan []byte
}

func newTestConn(c *Conn, bufferSize int) *testConn {
    return &testConn{
        conn:     c,
        messages: make(chan []byte, bufferSize),
    }
}

func printss() {
    m := runtime.MemStats{}
    runtime.ReadMemStats(&m)
    fmt.Printf("inuse: %d sys: %d\n", m.StackInuse, m.StackSys)
}

func TestWriteWithCompression(t *testing.T) {
    w := ioutil.Discard
    done := make(chan struct{})
    numConns := 1000
    numMessages := 1000
    conns := make([]*testConn, numConns)
    var wg sync.WaitGroup
    for i := 0; i < numConns; i++ {
        c := newConn(fakeNetConn{Reader: nil, Writer: w}, false, 1024, 1024)
        c.enableWriteCompression = true
        c.newCompressionWriter = compressNoContextTakeover
        conns[i] = newTestConn(c, 256)
        wg.Add(1)
        go func(c *testConn) {
            defer wg.Done()
            i := 0
            for i < numMessages {
                select {
                case <-done:
                    return
                case msg := <-c.messages:
                    c.conn.WriteMessage(TextMessage, msg)
                    i++
                }
            }
        }(conns[i])
    }
    messages := textMessages(100)
    for i := 0; i < numMessages; i++ {
        if i%100 == 0 {
            printss()
        }
        msg := messages[i%len(messages)]
        for _, c := range conns {
            c.messages <- msg
        }
    }
    wg.Wait()
}

func textMessages(num int) [][]byte {
    messages := make([][]byte, num)
    for i := 0; i < num; i++ {
        msg := fmt.Sprintf("planet: %d, country: %d, city: %d, street: %d", i, i, i, i)
        messages[i] = []byte(msg)
    }
    return messages
}

यह संपीड़न सक्षम के साथ 1000 कनेक्शन बनाता है, प्रत्येक बफर मैसेज चैनल के साथ है। फिर एक लूप में हम प्रत्येक कनेक्शन में संदेश लिखते हैं।

यहां बताया गया है कि यह go1.7.4 साथ कैसा व्यवहार करता है

fz<strong i="7">@websocket</strong>: go test -test.run=TestWriteWithCompression
inuse: 4259840 sys: 4259840
inuse: 27394048 sys: 27394048
inuse: 246251520 sys: 246251520
inuse: 1048510464 sys: 1048510464
inuse: 1048510464 sys: 1048510464
inuse: 1049034752 sys: 1049034752
inuse: 1049034752 sys: 1049034752
inuse: 1049034752 sys: 1049034752
inuse: 1049034752 sys: 1049034752
inuse: 1049034752 sys: 1049034752
PASS
ok      github.com/gorilla/websocket    11.053s

प्रतिबद्ध के साथ जाओ का उपयोग https://github.com/golang/go/commit/9c3630f578db1d4331b367c3c7d284db299be3a6

fz<strong i="12">@websocket</strong>: go1.8 test -test.run=TestWriteWithCompression
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
inuse: 4521984 sys: 4521984
PASS
ok      github.com/gorilla/websocket    12.023s

हालांकि फिलहाल यह कहना मुश्किल है कि यह समस्या इस समस्या को हल करेगी या नहीं।

मैंने भी flate https://github.com/klauspost/compress के साथ @klauspost द्वारा फ़िक्सेस शामिल हैं:

fz<strong i="20">@websocket</strong>: go test -test.run=TestWriteWithCompression
inuse: 4358144 sys: 4358144
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
inuse: 4587520 sys: 4587520
PASS
ok      github.com/gorilla/websocket    3.426s

लेकिन वास्तव में उस फिक्स के बिना भी https://github.com/klauspost/compress लाइब्रेरी बिना मेमोरी ग्रोथ के व्यवहार करती है ... मैं इसे समझा नहीं सकता।

यहां भी https://github.com/klauspost/compress लाइब्रेरी का उपयोग करके बेंचमार्क परिणाम है:

BenchmarkWriteWithCompression-4       200000          5676 ns/op         149 B/op          3 allocs/op

यह 4x स्पीडअप है, जो मानक lib compress/flate परिणामों की तुलना में है:

BenchmarkWriteWithCompression-4        50000         25362 ns/op         128 B/op          3 allocs/op

@ गैरीबर्ड मैं समझता हूं कि कोर में गैर-मानक

उस फिक्स के बिना भी [यह] बिना मेमोरी बढ़े व्यवहार करता है ... मैं इसे समझा नहीं सकता।

AFAICT, यह पैकेज "स्तर 3" संपीड़न (जो एक अच्छा विकल्प है) का उपयोग करता है। मेरे पैकेज स्तर में 1-4 एक विशेष है, और "जेनेरिक" कोड का उपयोग न करें, जिसमें समस्या है।

गो 1.7 के स्तर 1 (सर्वश्रेष्ठ गति) में एक समान विशिष्ट कार्य है। मुझे लगता है कि यदि आप इसका उपयोग करते हैं, तो आप समस्या का अनुभव नहीं करेंगे। यह एक ऐसा समाधान हो सकता है जिसका आप उपयोग कर सकते हैं, इसलिए आपको एक विशेष पैकेज आयात करने की आवश्यकता नहीं है (भले ही मैं उपयोगकर्ताओं को विकल्प देने के लिए बुरा न मानूँ)। स्तर 1 के लिए प्रदर्शन मेरे पैकेज के बहुत करीब होना चाहिए।

@klauspost को समझाने के लिए धन्यवाद, बस आपने क्या कहा - हाँ, सम्पीडन स्तर 1 के प्रदर्शन के साथ आपकी लाइब्रेरी के लिए तुलनीय है और go1.7 में कोई स्मृति समस्या नहीं है (ऊपर परीक्षण मामले में)

@ गैरीबर्ड आप इस बारे में क्या सोचते हैं? मैं दो समाधान देखता हूं जो हमारी मदद कर सकते हैं - संपीड़न स्तर के निर्यात किए गए चर बनाएं या कस्टम फ्लैट कार्यान्वयन को प्लग करने की अनुमति दें। बेशक हम go1.8 की प्रतीक्षा कर सकते हैं लेकिन संपीड़न के प्रदर्शन में सुधार करने का एक तरीका अभी भी बहुत महत्वपूर्ण है। क्या आप चाहते हैं कि हम आपके द्वारा दी गई सलाह के साथ कस्टम बिल्ड बनाने की कोशिश करें और निश्चित कॉपी कॉपी बग देखें और देखें कि यह उत्पादन में कैसे व्यवहार करता है?

@FZambia अब एक के लिए संपीड़न स्तर सेट करने के बारे में कैसे? यह शायद इस समय अधिकांश अनुप्रयोगों के लिए सबसे अच्छा विकल्प है और अधिक एपीआई सतह क्षेत्र को उजागर करने से बचा जाता है।

@garyburd मैं हूं , संपीड़न सेट करने का विकल्प होने से मेरे विशेष उपयोग के मामले में, मेरे पास 200K उपयोगकर्ताओं के लिए प्रति सेकंड 80K संदेशों का एक प्रशंसक है, जो बहुत अधिक ट्रैफ़िक का कारण बनता है, अगर मैं सक्षम होऊंगा कम्प्रेशन लेवल सेट करने के लिए मैं सर्वर नंबरों और ट्रैफ़िक के बीच का मधुर स्थान ढूंढ सकता हूँ।
आमतौर पर, सर्वर ट्रैफिक की तुलना में बहुत कम खर्च करते हैं जब ट्रैफिक इतना अधिक होता है तो इस विकल्प को कॉन्फ़िगर करना बहुत बढ़िया होगा
धन्यवाद

ठीक है, चलो निम्नलिखित जोड़ते हैं:

type CompressionOptions {
    // Level specifies the compression level for the flate compressor.  Valid levels range from
    // -2 to 9.  Level -2 will use Huffman compression only. Level -1 uses the default compression 
    // level.  Level 0 does not attempt any compression.  Levels 1 through 9 range from best
    // speed to best compression. 
    // 
    // Applications should set this field.  The default value of 0 does not attempt any compression.
    Level int
}

type Dialer struct {
   // CompressionOptions specifies options the client should use for 
   // per message compression (RFC 7692).  If CompressionOptions is nil and
   // EnableCompression is nil, then the client does not attempt to negotiate
   // compression with the server.
   CompressionOptions *CompressionOptions

  // EnableCompression specifies if the client should attempt to negotiate
  // per message compression (RFC 7692). Setting this value to true does not
  // guarantee that compression will be supported. Currently only "no context
  // takeover" modes are supported.
  //
  // Deprecated: Set CompressionOptions to non-nil value to enable compression
  // negotiation.
  EnableCompression bool
}

डायलर को मिलान करने के लिए ऊपर को संशोधित करें।

@ गैरीबर्ड मैं मानता हूं कि स्तर 1 इस समय डिफ़ॉल्ट मान के लिए बेहतर है क्योंकि यह मेमोरी को Go1.7 पर बढ़ता है और संपीड़न इतना महंगा है। लेकिन इतने बड़े ऐप्स में फैनआउट स्तर पर ऐसा लगता है जैसे @joshdvir में बैंडविड्थ की बचत बचते हैं, जिससे कम्प्रेशन लेवल विन्यास योग्य हो जाता है।

हमने संपीड़न स्तर 1 के साथ एक कस्टम बिल्ड बनाया और आपके द्वारा सुझाए गए काउंटरों और इसे उत्पादन में डाल दिया। काउंटर मान हैं:

Node 1:
"gorilla_websocket_flate_writer_from_pool": 1453147,
"gorilla_websocket_new_flate_writer": 6702

Node 2:
"gorilla_websocket_flate_writer_from_pool": 1820919,
"gorilla_websocket_new_flate_writer": 3676,

Node 3:
"gorilla_websocket_flate_writer_from_pool": 574187,
"gorilla_websocket_new_flate_writer": 321

...

यह 1 मिनट से अधिक एकत्रीकरण है। तो पूल बहुत प्रभावी दिखता है लेकिन ...

... संपीड़न अभी भी allocs और CPU प्रोफाइल में अग्रणी है और सिंक से प्राप्त कर रहा है। किसी कारण से सबसे अधिक आवंटन-महंगा ऑपरेशन है।

यहाँ सीपीयू प्रोफ़ाइल अब है:

(pprof) top 30 --cum
27.28s of 52.42s total (52.04%)
Dropped 414 nodes (cum <= 0.26s)
Showing top 30 nodes out of 137 (cum >= 1.89s)
      flat  flat%   sum%        cum   cum%
         0     0%     0%     50.21s 95.78%  runtime.goexit
     0.16s  0.31%  0.31%     43.93s 83.80%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessages
     0.21s   0.4%  0.71%     42.52s 81.11%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessage
     0.19s  0.36%  1.07%     42.31s 80.71%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*wsSession).Send
     0.21s   0.4%  1.47%     41.87s 79.87%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage
     0.01s 0.019%  1.49%     35.43s 67.59%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*flateWriteWrapper).Close
     0.03s 0.057%  1.55%     24.69s 47.10%  compress/flate.(*Writer).Flush
         0     0%  1.55%     24.66s 47.04%  compress/flate.(*compressor).syncFlush
     0.04s 0.076%  1.62%     24.03s 45.84%  compress/flate.(*compressor).encSpeed
     0.08s  0.15%  1.77%     18.16s 34.64%  compress/flate.(*huffmanBitWriter).writeBlockDynamic
     0.12s  0.23%  2.00%     15.03s 28.67%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*messageWriter).flushFrame
     0.11s  0.21%  2.21%     14.90s 28.42%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).write
     0.91s  1.74%  3.95%     13.21s 25.20%  compress/flate.(*huffmanEncoder).generate
         0     0%  3.95%     12.72s 24.27%  net.(*conn).Write
     0.06s  0.11%  4.06%     12.72s 24.27%  net.(*netFD).Write
    11.78s 22.47% 26.54%     12.16s 23.20%  syscall.Syscall
     0.05s 0.095% 26.63%     12.09s 23.06%  syscall.Write
     0.02s 0.038% 26.67%     12.04s 22.97%  syscall.write
     0.61s  1.16% 27.83%     11.98s 22.85%  compress/flate.(*huffmanBitWriter).indexTokens
         0     0% 27.83%     10.61s 20.24%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*messageWriter).Close
     5.20s  9.92% 37.75%      6.62s 12.63%  compress/flate.(*huffmanEncoder).bitCounts
     4.77s  9.10% 46.85%      5.44s 10.38%  compress/flate.encodeBestSpeed

सूची लिखें

(pprof) list WriteMessage
Total: 52.42s
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/conn.go
     210ms     41.87s (flat, cum) 79.87% of Total
         .          .    659:
         .          .    660:// WriteMessage is a helper method for getting a writer using NextWriter,
         .          .    661:// writing the message and closing the writer.
         .          .    662:func (c *Conn) WriteMessage(messageType int, data []byte) error {
         .          .    663:
     160ms      160ms    664:   if c.isServer && (c.newCompressionWriter == nil || !c.enableWriteCompression) {
         .          .    665:
         .          .    666:       // Fast path with no allocations and single frame.
         .          .    667:
      10ms       40ms    668:       if err := c.prepWrite(messageType); err != nil {
         .          .    669:           return err
         .          .    670:       }
         .          .    671:       mw := messageWriter{c: c, frameType: messageType, pos: maxFrameHeaderSize}
         .       80ms    672:       n := copy(c.writeBuf[mw.pos:], data)
         .          .    673:       mw.pos += n
         .          .    674:       data = data[n:]
      10ms      4.43s    675:       return mw.flushFrame(true, data)
         .          .    676:   }
         .          .    677:
         .      1.63s    678:   w, err := c.NextWriter(messageType)
         .          .    679:   if err != nil {
         .          .    680:       return err
         .          .    681:   }
      30ms      100ms    682:   if _, err = w.Write(data); err != nil {
         .          .    683:       return err
         .          .    684:   }
         .     35.43s    685:   return w.Close()

सूची बंद करें

         .          .    104:func (w *flateWriteWrapper) Close() error {
         .          .    105:   if w.fw == nil {
         .          .    106:       return errWriteClosed
         .          .    107:   }
         .     24.69s    108:   err1 := w.fw.Flush()
      10ms      130ms    109:   flateWriterPool.Put(w.fw)
         .          .    110:   w.fw = nil
         .          .    111:   if w.tw.p != [4]byte{0, 0, 0xff, 0xff} {
         .          .    112:       return errors.New("websocket: internal error, unexpected bytes at end of flate stream")
         .          .    113:   }
         .     10.61s    114:   err2 := w.tw.w.Close()
         .          .    115:   if err1 != nil {
         .          .    116:       return err1
         .          .    117:   }
         .          .    118:   return err2
         .          .    119:}

सूची फ्लश

         .          .    711:// In the terminology of the zlib library, Flush is equivalent to Z_SYNC_FLUSH.
         .          .    712:func (w *Writer) Flush() error {
         .          .    713:   // For more about flushing:
         .          .    714:   // http://www.bolet.org/~pornin/deflate-flush.html
      30ms     24.69s    715:   return w.d.syncFlush()
         .          .    716:}
         .          .    717:
         .          .    718:// Close flushes and closes the writer.
         .          .    719:func (w *Writer) Close() error {
         .          .    720:   return w.d.close()
ROUTINE ======================== compress/flate.(*compressor).syncFlush in /Users/fz/go1.7/src/compress/flate/deflate.go
         0     24.66s (flat, cum) 47.04% of Total
         .          .    555:func (d *compressor) syncFlush() error {
         .          .    556:   if d.err != nil {
         .          .    557:       return d.err
         .          .    558:   }
         .          .    559:   d.sync = true
         .     24.03s    560:   d.step(d)
         .          .    561:   if d.err == nil {
         .      490ms    562:       d.w.writeStoredHeader(0, false)
         .      140ms    563:       d.w.flush()
         .          .    564:       d.err = d.w.err
         .          .    565:   }
         .          .    566:   d.sync = false
         .          .    567:   return d.err
         .          .    568:}

मेमोरी का उपयोग अब बहुत बेहतर है लेकिन यह अभी भी बहुत अधिक है, संपीड़न बहुत कुछ आवंटित करता है:

fz<strong i="9">@centrifugo</strong>: go tool pprof --alloc_space centrifugo heap_profile_extra 
Entering interactive mode (type "help" for commands)
(pprof) top 30 --cum
518.97GB of 541.65GB total (95.81%)
Dropped 314 nodes (cum <= 2.71GB)
Showing top 30 nodes out of 35 (cum >= 3.33GB)
      flat  flat%   sum%        cum   cum%
         0     0%     0%   541.53GB   100%  runtime.goexit
         0     0%     0%   505.54GB 93.33%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessages
         0     0%     0%   504.45GB 93.13%  github.com/centrifugal/centrifugo/libcentrifugo/conns/clientconn.(*client).sendMessage
         0     0%     0%   504.45GB 93.13%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*wsSession).Send
         0     0%     0%   504.45GB 93.13%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).WriteMessage
    6.63GB  1.22%  1.22%   501.75GB 92.63%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextWriter
    6.56GB  1.21%  2.44%   495.11GB 91.41%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover
         0     0%  2.44%   491.89GB 90.81%  sync.(*Pool).Get
         0     0%  2.44%   491.89GB 90.81%  sync.(*Pool).getSlow
  359.74GB 66.42% 68.85%   488.55GB 90.20%  compress/flate.NewWriter
         0     0% 68.85%   488.55GB 90.20%  github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.glob..func1
  128.81GB 23.78% 92.63%   128.81GB 23.78%  compress/flate.(*compressor).init
    0.01GB 0.0019% 92.64%    28.97GB  5.35%  net/http.(*conn).serve
         0     0% 92.64%    25.18GB  4.65%  github.com/centrifugal/centrifugo/libcentrifugo/server/httpserver.(*HTTPServer).Logged.func1
         0     0% 92.64%    25.18GB  4.65%  net/http.(*ServeMux).ServeHTTP
         0     0% 92.64%    25.18GB  4.65%  net/http.HandlerFunc.ServeHTTP
         0     0% 92.64%    25.18GB  4.65%  net/http.serverHandler.ServeHTTP

सूची NextWriter

(pprof) list NextWriter
Total: 541.65GB
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.(*Conn).NextWriter in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/conn.go
    6.63GB   501.75GB (flat, cum) 92.63% of Total
         .          .    444:   }
         .          .    445:
         .          .    446:   mw := &messageWriter{
         .          .    447:       c:         c,
         .          .    448:       frameType: messageType,
    6.63GB     6.63GB    449:       pos:       maxFrameHeaderSize,
         .          .    450:   }
         .          .    451:   c.writer = mw
         .          .    452:   if c.newCompressionWriter != nil && c.enableWriteCompression && isData(messageType) {
         .   495.11GB    453:       w := c.newCompressionWriter(c.writer)
         .          .    454:       mw.compress = true
         .          .    455:       c.writer = w
         .          .    456:   }
         .          .    457:   return c.writer, nil
         .          .    458:}

सूची compressNoContextTakeover

(pprof) list compressNoContextTakeover
Total: 541.65GB
ROUTINE ======================== github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket.compressNoContextTakeover in /Users/fz/go/src/github.com/centrifugal/centrifugo/vendor/github.com/gorilla/websocket/compression.go
    6.56GB   495.11GB (flat, cum) 91.41% of Total
         .          .     44:   fr.(flate.Resetter).Reset(io.MultiReader(r, strings.NewReader(tail)), nil)
         .          .     45:   return &flateReadWrapper{fr}
         .          .     46:}
         .          .     47:
         .          .     48:func compressNoContextTakeover(w io.WriteCloser) io.WriteCloser {
    4.41GB     4.41GB     49:   tw := &truncWriter{w: w}
         .   488.55GB     50:   fw, _ := flateWriterPool.Get().(*flate.Writer)
         .          .     51:   plugin.Metrics.Counters.Inc("gorilla_websocket_flate_writer_from_pool")
         .          .     52:   fw.Reset(tw)
    2.15GB     2.15GB     53:   return &flateWriteWrapper{fw: fw, tw: tw}
         .          .     54:}

--inuse_space समान चित्र केवल समान मात्रा के दो क्रम को कम करके दिखाता है (2.69GB flateWriterPool.Get () के लिए। (* flate.Writer) लाइन जो नेता है)।

यह कहना मुश्किल है कि हम इतने बड़े कंप्रेशन के साथ क्या कर सकते हैं ...

@garyburd आपको CompressionOptions जोड़ने का सुझाव देता है - मैं इसके साथ पुल अनुरोध कर सकता हूं, लेकिन शायद DefaultFlateCompressionLevel जैसा एक वैश्विक निर्यातित चर जिसे हम एप्लिकेशन प्रारंभ या सेट्टर विधि पर सेट कर सकते हैं? हमें प्रति-कनेक्शन संपीड़न स्तर की आवश्यकता नहीं है - और हम अंततः वही कर सकते हैं जो आपने सुझाया था यदि बाद में आवश्यकता होगी। और अब इस तरह से किसी भी तरह के अपचयन की आवश्यकता नहीं होगी।

@FZambia पूल प्रभावशीलता का परीक्षण करने और प्रोफाइल की रिपोर्ट करने के लिए धन्यवाद।

मैं अब एक ऐसा एपीआई नहीं जोड़ना चाहता जो बाद में दूसरे एपीआई के साथ बदल सके।

जैसा कि मैं इसके बारे में अधिक सोचता हूं, एक विधि जोड़ना बेहतर है:

// SetCompressionLevel sets the flate compression level for the next message.
// Valid levels range from -2 to 9.  Level -2 will use Huffman compression only. 
// Level -1 uses the default compression  level.  Level 0 does not attempt any
// compression.  Levels 1 through 9 range from best speed to best compression. 
func (c *Conn) SetCompressionLevel(n int) error {
}

यह अन्य विकल्पों की तुलना में अधिक लचीला है। कार्यान्वयन फ्लैटवेटरपूल [12] के साथ flateWriterPool को बदल देगा। FlateWriterWrapper को स्तर को स्टोर करने की आवश्यकता होगी ताकि लेखक को सही पूल में लौटाया जा सके।

मुझे लगता है कि डिफ़ॉल्ट संपीड़न स्तर को बदलने वाला एक तरीका अभी भी समझ में आता है:

var defaultCompressionLevel int = 1

// SetDefaultCompressionLevel sets the flate compression level which will be used by 
// default to compress messages when compression negotiated. This function must be 
// called once before application starts.
//
// Valid levels range from -2 to 9.  Level -2 will use Huffman compression only. 
// Level -1 uses the default compression  level.  Level 0 does not attempt any
// compression.  Levels 1 through 9 range from best speed to best compression. 
func (c *Conn) SetDefaultCompressionLevel(n int) error {
    defaultCompressionLevel = n
}

ज्यादातर स्थितियों में मुझे लगता है कि कस्टम कंप्रेशन की जरूरत वाले यूजर्स को इस डिफ़ॉल्ट वैल्यू को एक बार सेट करना होगा।

फिर अगर किसी को प्रति कनेक्शन / संदेश में संपीड़न स्तर की आवश्यकता होती है, तो हम SetCompressionLevel और एक [12] flateWrPPP जोड़ सकते हैं:

// SetCompressionLevel sets the flate compression level for the next message.
// Valid levels range from -2 to 9.  Level -2 will use Huffman compression only. 
// Level -1 uses the default compression  level.  Level 0 does not attempt any
// compression.  Levels 1 through 9 range from best speed to best compression.
// If not set default compression level will be used.
func (c *Conn) SetCompressionLevel(n int) error {
}

यदि इसे नहीं बुलाया जाता है, लेकिन संपीड़न ने defaultCompressionLevel उपयोग किया तो बातचीत होगी। वर्तमान में लागू होने से पहले एक बार जो कैविएट मैं देख रहा हूं कि SetDefaultCompressionLevel एक बार कॉल किया जाना चाहिए, लेकिन यह बहुत अपारदर्शी लगता है।

बस प्रत्येक flate.Writer उदाहरण के आकार को देखा:

package main

import "unsafe"
import "compress/flate"

func main() {
    var w flate.Writer
    println(unsafe.Sizeof(w))
}

600Kb! यह आकार मेरे लिए आश्चर्यजनक है - मैंने यह भी नहीं माना है कि यह इतनी बड़ी बात है :)

हाँ - राज्य को बनाए रखने के लिए, हफ़मैन टेबल और बफर आउटपुट का उत्पादन करने के लिए काफी तालिकाओं की आवश्यकता होती है। मानक पुस्तकालय में स्तर -2 (हफ़मैनऑली), 0 (कोई संपीड़न नहीं) और 1 (सर्वश्रेष्ठ गति) को छोड़कर, इसके बारे में बहुत कुछ नहीं किया जा सकता है।

अपनी खुद की लाइब्रेरी के लिए मैं कई बफर के रूप में इनकोडिंग विकल्पों के लिए मेमोरी आवश्यकताओं को कम करने के लिए देख रहा हूं, जिन्हें https://github.com/klauspost/compress/pull/70 (यह अभी भी समस्या है, जैसा देखा जा सकता है) देखें दुर्घटना से मैं मुद्दे में लॉग इन)

@FZambia मैं सेटिंग्स के लिए पैकेज स्तर चर का उपयोग नहीं करना चाहता। सेटिंग को डायलर और उप्रगडर में अन्य सेटिंग्स के साथ शामिल किया जाना चाहिए या यह कनेक्शन का हिस्सा होना चाहिए ताकि इसे संदेश से संदेश में बदला जा सके।

B0dc45572b148296ddf01989da00a2923d213a56 देखें।

@ गैरीबर्ड ने इस समय हमारी मदद करने के लिए आपका बहुत धन्यवाद दिया। इन सभी प्रोफाइलों को देखते हुए क्या आप संपीड़न मेमोरी उपयोग और आवंटन को कम करने का कोई तरीका देखते हैं?

यदि एप्लिकेशन कई क्लाइंट को एक ही संदेश भेजता है, तो # 182 अगली कोशिश है।

@garyburd # 182 मेरे उपयोग के मामले में जादू कर सकता है, जहां मेरा प्रशंसक 50K-90K प्रति सेकंड के बीच है जहां सभी संदेश समान हैं।

आपके सहयोग के लिए धन्यवाद।

क्या यह समस्या b0dc45572b148296ddf01989da00a2923d213a56 और 804cb600d06b10672f2fbc0a336a7bb5050aa428e द्वारा तय की गई है?

परिवर्तन से पहले @ गैरीबर्ड ढेर:

परिवर्तनों के बाद (संपीड़न स्तर 1 और PreparedMessage का उपयोग करके):

सीपीयू के लिए एक ही तस्वीर। इसलिए हम पहले स्थान पर ढेर और सीपीयू प्रोफाइल में संपीड़न नहीं देखते हैं।

हालांकि स्मृति उपयोग कम हो गया है यह संपीड़न का उपयोग करते समय अभी भी बहुत अधिक है - लेकिन यह अनुप्रयोग समस्या हो सकती है, हम जांच करने का प्रयास करेंगे

@garyburd ने केवल inuse_space प्रोफ़ाइल की घोषणा की @joshdvir ने मुझे दिया।

नेता gorilla/websocket.newConnBRW (36%), http.newBufioWriterSize (17%), http.newBufioReader (16%) हैं। मुझे लगा कि हमने हाल ही में आपके द्वारा # 223 में जोड़े गए सुधार का उपयोग किया है, लेकिन जिन प्रोफाइल पर मैंने गौर किया है, उन्होंने देखा कि hijack से बफ़र्स पढ़ना और लिखना किसी कारण से पुन: उपयोग नहीं किया जाता है। तब मुझे सेंट्रीफुगो कोड में एक बग मिला - ReadBufferSize और WriteBufferSize कॉन्फ़िगरेशन में सेट किए गए उन आकारों के मामले में SockJS-go डिफ़ॉल्ट मान (4096) थे। तय करने के साथ निर्माण करेगा और परिणामों के साथ वापस आएगा।

प्रोफाइल में कुछ अन्य चीजें हैं जो आपको रुचि दे सकती हैं - मैं निर्माण के साथ svg ग्राफ विज़ुअलाइज़ेशन को फिक्स के साथ अपलोड करने का प्रयास करूंगा।

नवीनतम गोरिल्ला वेबसोकेट के साथ सेंट्रीफुगो का उपयोग करने वाले कुछ ग्राफ़ यहां दिए गए हैं। यह @joshdvir द्वारा

CPU:

यहाँ हम देखते हैं कि अधिकांश सीपीयू syscalls पर खर्च होते हैं - पढ़ते हैं, लिखते हैं - मुझे नहीं लगता कि हम यहाँ बहुत कुछ कर सकते हैं, क्योंकि हम अलग-अलग सॉकेट में बहुत सारे फैनआउट संदेश भेजते हैं। तो यह सामान्य लग रहा है।

स्थान आवंटित करें:

यहां हम compress/flate.(*decompressor).Reset का एक बड़ा प्रभाव देखते हैं - मैंने सोचा कि इसे कैसे सुधारें, लेकिन अभी तक कोई रास्ता नहीं मिला है।

अंतरिक्ष में प्रयोग करें:

@ गैरीबर्ड आपको आगे चीजों को बेहतर बनाने का एक तरीका दिखाई देता है? यदि नहीं, तो हम इसके साथ रह सकते हैं मुझे लगता है।

पीएस मैं स्थानीय मशीन पर संपीड़न सक्षम / अक्षम और प्रोफाइल की तुलना के साथ कई ws कनेक्शन बनाने जा रहा हूं।

मुझे कुछ ट्विक्स मिले जो कि डिकोडर को आवंटन से बचने के लिए किया जा सकता था, और 4KB के बारे में आवंटन को स्थगित करना जब यह वास्तव में आवश्यक हो।

https://github.com/klauspost/compress/pull/76

मुझे वेबसैट पैकेज में सुधार के लिए कुछ भी स्पष्ट नहीं दिख रहा है।

बस लोकलहोस्ट पर कोशिश की जाती है - ऐसा लगता है कि मेमोरी की खपत अलग-अलग जगहों से कम या ज्यादा समान अनुपात में होती है इसलिए काम करने के लिए अड़चन का निदान करना मुश्किल है। मुझे लगता है कि हम यहाँ उस समय के लिए कर रहे हैं।

@क्लासपोस्ट मैंने स्थानीय सेटअप पर भी आपके कॉम्प्रेसेड लिब की कोशिश की (1000 क्लाइंट्स को नोड से कनेक्ट करें) - मेरे मामले में मेमोरी की खपत बिना कंप्रेशन के 50 ग्राम, एसटीडी की कम्प्रेशन कम्प्रेशन के साथ 90mb, पैच के बिना आपकी लिबास के साथ 90mb और पैच https के साथ आपके 85mb की है।

Go1.8.1 से गो 1.7.5 में अद्यतन करने से मेरे कृत्रिम स्थानीय सेटअप पर लगभग 15% (90mb -> 75mb) से मेमोरी उपयोग में सुधार हुआ। लेकिन मैं बिल्कुल नहीं कह सकता कि यह लाभ कहां से आया।

सम्पीडन सक्षम मेमोरी के साथ उत्पादन उदाहरण पर भी गो 1.8 के साथ समान 15-20% पर गिर गया

@joshdvir @FZambia (और अन्य), क्या हमें लगता है कि इस मुद्दे को गो मानक पुस्तकालय में सुधार के साथ संबोधित किया गया है या अभी भी कुछ नीचे ट्रैक करने के लिए है?

@theckman हाय, मेरे पास कोई विचार नहीं है कि हम आगे कैसे संपीड़न प्रदर्शन में सुधार कर सकते हैं। मुझे नहीं लगता कि समस्या पूरी तरह से हल हो गई है क्योंकि संपीड़न अभी भी प्रदर्शन को बहुत प्रभावित करता है। लेकिन अगर आप इस मुद्दे को बंद करने की योजना बना रहे हैं - इसे बेझिझक करें क्योंकि यह क्षितिज पर कोई स्पष्ट समाधान नहीं है। स्थिति के आधार पर PreparedMessage एक जीवन रक्षक हो सकता है लेकिन मुझे व्यक्तिगत रूप से इसकी अवधारणा बहुत पसंद नहीं है क्योंकि यह बहुत विशिष्ट है और कनेक्शन में बाइट्स लिखने के शब्दार्थ को तोड़ता है।

हो सकता है कि अगर आपने एक काफी स्टैंडअलोन बेंचमार्क लिखा है, जिसका अर्थ केवल स्टैडलिब और डिफ्लेट का उपयोग करना है जो वास्तविक दुनिया के परिदृश्यों का प्रतिनिधित्व करता है जो कि मैं परीक्षण के लिए एक बेंचमार्क के रूप में उपयोग कर सकता हूं यदि एक लीनर एनकोडर वास्तव में मदद करेगा।

पीआर खुद को फिर से लिखना होगा, लेकिन एक अच्छा बेंचमार्क होना एक शुरुआती बिंदु होगा।

हम एक []byte -> []byte API भी जोड़ सकते हैं, जहां पूर्ण फ्रेम की आपूर्ति की जाती है जो आंतरिक बफर (और इसे कॉपी करने के दंड) की आवश्यकता को समाप्त कर देगा।

इन प्रदर्शन मुद्दों को देखते हुए, संपीड़न सक्षम करने योग्य है?

हम एक [] बाइट -> [] बाइट एपीआई भी जोड़ सकते हैं, जहां पूर्ण फ्रेम की आपूर्ति की जाती है जो एक आंतरिक बफर (और इसे कॉपी करने के दंड) की आवश्यकता को समाप्त कर देगा।

यह एपीआई कैसे काम करेगा? क्या हम सीधे net.Conn पर लिखने की अनुमति देंगे?

संपीड़न के बिना सर्वर पर, WriteMessage API ज्यादातर अंतर्निहित नेटवर्क कनेक्शन के लिए दिए गए [] बाइट से सीधे डेटा की प्रतिलिपि बनाता है। तैयार संदेश एपीआई भी अंतर्निहित नेटवर्क कनेक्शन के लिए सीधे [] बाइट की प्रतिलिपि बनाता है।

मेरा मानना ​​है कि यह मुद्दा संपीड़ित होने के कारण है। Https://golang.org/issue/3155 देखें

इस प्रकार, प्रत्येक फ्लैट लेखक बहुत सारी मेमोरी आवंटित करता है और भले ही वे पूल के माध्यम से पुन: उपयोग किए जाते हैं, यह अंत में संपीड़न के साथ बड़े मेमोरी उपयोग स्पाइक का कारण बनता है।

ऐसा नहीं लगता है कि यह समस्या बंद होने तक यह लाइब्रेरी आगे भी कुछ कर सकती है।

वास्तव में, इस बेंचमार्क के अनुसार

func BenchmarkFlate(b *testing.B) {
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        flate.NewWriter(nil, flate.BestSpeed)
    }
}

$ go test -bench=BenchmarkFlate -run=^$
goos: darwin
goarch: amd64
pkg: scratch
BenchmarkFlate-8       10000        131504 ns/op     1200008 B/op         15 allocs/op
PASS
ok      scratch 1.345s

flate.NewWriter 1.2 MB आवंटित करता है! जब आप 600 बाइट वेबस्केट संदेश लिख रहे हैं, तो संपीड़न के लिए आवंटित करने के लिए यह बहुत मेमोरी है।

BestCompression या DefaultCompress के साथ, आवंटन 800 केबी गिरा देता है लेकिन यह अभी भी बड़े पैमाने पर है।

# DefaultCompression
$ go test -bench=BenchmarkFlate -run=^$
goos: darwin
goarch: amd64
pkg: nhooyr.io/websocket
BenchmarkFlate-8       20000         93332 ns/op      806784 B/op         13 allocs/op
PASS
ok      nhooyr.io/websocket 2.848s
# BestCompression
$ go test -bench=BenchmarkFlate -run=^$
goos: darwin
goarch: amd64
pkg: nhooyr.io/websocket
BenchmarkFlate-8       20000         95197 ns/op      806784 B/op         13 allocs/op
PASS
ok      nhooyr.io/websocket 2.879s

मैंने गोलंग दायर किया है / # 32371 जाओ

Https://github.com/klauspost/compress/pull/176 पर एक नजर डालें

@klauspost जो वास्तव में अच्छा है। प्रत्येक लिखें के लिए किस प्रकार की मेमोरी ओवरहेड शामिल होगी?

यह कुछ सौ किलोबाइट की आवश्यकता होगी, लेकिन एक बार जब यह संकुचित हो जाता है तो अन्य विकल्पों से पहले के विपरीत स्मृति को मुक्त कर दिया जाएगा।

वेब सॉकेट्स के लिए, जो आपको चाहिए। मतलब निष्क्रिय सॉकेट के लिए कोई लाइव आवंटन नहीं। बस यकीन है कि सभी एक ही लेखन में लिखा है।

@klauspost धन्यवाद, मैं समय मेरे पास एक जिस्ट है जो गोरिल्ला वेबस्केट लाइब्रेरी के साथ कस्टम फ्लेट का उपयोग करने की अनुमति देता है - इसे फिर से बनाने और अपनी स्टेटलेस कम्प्रेशन ब्रांच के साथ प्रयोग करने की आवश्यकता है।

https://github.com/klauspost/compress/pull/185 एक आंतरिक sync.Pool होने पर लिखकर कुछ सौ बाइट्स में ढेर आवंटन को कम करता है।

स्टेटलेस कम्प्रेशन के साथ @klauspost की लाइब्रेरी के मेरे परीक्षण ने शानदार परिणाम दिखाए हैं।

Https://github.com/klauspost/compress/pull/216#issuecomment -586660128 देखें

लगभग 512 KB प्रति संदेश सरल 512 बाइट संदेश []byte(strings.Repeat("1234", 128)) लिए लिखा गया है।

संपादित करें: यह अब मेरी लाइब्रेरी पर मास्टर में परीक्षण के लिए उपलब्ध है।

स्पष्ट करने के लिए, यह संदर्भ टेकओवर मोड में एक शब्दकोश के साथ है, यह 50 बी है एक संदेश आवंटित किया जाता है अगर कोई शब्दकोश नहीं है।