Compression in MongoDb 3.2 does not work I installed MongoDb 3.2, and configured snappy compression in mongodb configuration file:

engine: wiredTiger
   wiredTiger:
       engineConfig:
           cacheSizeGB: 99
           journalCompressor: none
       collectionConfig:
           blockCompressor: snappy
       indexConfig:
           prefixCompression: true

However I do not think compression actually work as I could see average object size in the collection is about the same (I filled collection created from scratch by the same objects right after configuration change and service restart):

MMAPv1 no-compression avgObjSize: 5kb
WiredTiger snappy avgObjSize: 4kb
WiredTiger zlib avgObjSize: 4kb


when I run stats on collection here is what I see for "snappy":

"compression" : {
        "compressed pages read" : NumberInt(0), 
        "compressed pages written" : NumberInt(5), 
        "page written failed to compress" : NumberInt(0), 
        "page written was too small to compress" : NumberInt(4), 
        "raw compression call failed, additional data available" : NumberInt(0), 
        "raw compression call failed, no additional data available" : NumberInt(0), 
        "raw compression call succeeded" : NumberInt(0)
    },


for zlib:

{
    "compressed pages read" : NumberInt(0), 
    "compressed pages written" : NumberInt(1), 
    "page written failed to compress" : NumberInt(0), 
    "page written was too small to compress" : NumberInt(3), 
    "raw compression call failed, additional data available" : NumberInt(0), 
    "raw compression call failed, no additional data available" : NumberInt(1), 
    "raw compression call succeeded" : NumberInt(2)
}


Not sure how to read this info, and not sure how can I detect what's wrong with compression.

I should also say I had only few (like 10) objects in each scenario. Would it be enough to accurately measure average object compression ratio?

UPDATE: with 1188 documents mongodb ver3 shown around 50% better compression ratio comparing to mongodb ver2.6 (MMAPv1), however got no difference between snappy and zlib: dataSize and avgObjSize are the same for some reason. When I request statistics it shown WiredTiger:creationString:...block_compressor=zlib.. for the first database and block_compressor=snappy for the second one, so databases and collections seemed to be created with right compression algorithms
--version 3.4.10 Enterprise

compression will not change the avgObjSize. It will just improve the compression ratio saving disk space; I tested it for a collection (documents: 11553423 and avgObjSize= 6182) worth 21GB  with snappy, when same created with zlib, size of collection reduced to 12GB (avgObjSize= 6182).