How do i relate MongoDB 3.2.1 (WiredTiger Storage Enginer) INSERT and READ
performance with disk performance of SATA disk ?
Performance measurement is a deep subject and depends on many interrelated
things. Disk is only one part of the equation, and its performance may
depend on the interplay between the CPU speed, the amount of RAM, the
nature of the collection (e.g. document sizes, index sizes, etc.), the size
of the swap file, the use of compression in WiredTiger, the use of caching,
other processes running in the system, the configuration of the O/S, and
many other things. This is the reason why relating advertised disk
performance to actual MongoDB performance is difficult.
In the write test, please note that besides writing the data files into
disk, WiredTiger also uses journaling by default, and will write the
journal every 50 ms to disk. Please see Journaling Process
more information. Enabling WiredTiger compression could also alter the
result, since highly compressible documents will result in smaller amount
of disk writes compared to incompressible documents. However, please note
that compression also depends on CPU speed.
In the read test, the nature of the data in the database directly affects
the outcome. For example, if you have enough RAM to hold the working set in
memory, then the only way to induce MongoDB to use the disk is to perform a
collection scan. But this also depends on whether the data is also present
in the filesystem cache (in which case, MongoDB does not need to pull data
from disk). Enabling WiredTiger compression also allows the filesystem
cache to hold more data, thus lessening the need for MongoDB to read from
If you need to satisfy a certain Service Level Agreement (SLA) with your
MongoDB deployment (e.g. reads and writes should not take more than 10ms),
then measuring the response time of the overall system could be a better
metric compared to disk performance alone.