-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: 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) .
- is related to
-
SERVER-80150 Log negotiated network compressor with client metadata
- Closed
- related to
-
DRIVERS-1335 Improve Awareness of Network Compressors for Drivers
- Backlog