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

Differentiate serverStatus.network.compression by internal and external sources

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch

      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) .

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            alex.bevilacqua@mongodb.com Alex Bevilacqua
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: