Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-79842

Differentiate serverStatus.network.compression by internal and external sources

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Service Arch

    Description

      serverStatus performance counters for network.compression can't currently be used to identify to what degree application traffic is compressed as (compressed) replication traffic (SERVER-3018) would also be incrementing these counters.

      For example:

      Atlas atlas-7cbfmf-shard-0 [primary] test> db.serverStatus().network
      {
        [...]
        compression: {
          snappy: {
            compressor: { bytesIn: Long("774633295"), bytesOut: Long("544876919") },
            decompressor: { bytesIn: Long("475303790"), bytesOut: Long("730245460") }
          },
          zstd: {
            compressor: { bytesIn: Long("0"), bytesOut: Long("0") },
            decompressor: { bytesIn: Long("0"), bytesOut: Long("0") }
          },
          zlib: {
            compressor: { bytesIn: Long("0"), bytesOut: Long("0") },
            decompressor: { bytesIn: Long("0"), bytesOut: Long("0") }
          }
        },
        [...]
      }
      

      If the snappy network compressor were being used by one or more applications there would be no way to identify how much compressed application traffic was being generated (as snappy is the current default for networkMessageCompressors) .

      Attachments

        Activity

          People

            backlog-server-servicearch Backlog - Service Architecture
            alex.bevilacqua@mongodb.com Alex Bevilacqua
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: