In terms of performance, it’s basically what @steevej said.
I would like to know what will be the impact of cache eviction in the production environment.
Cache eviction means exactly that. It’s basically WiredTiger needing to empty some space in its cache (working memory) to make room for data that needs to be loaded from disk. The data in the cache can be clean (not modified) or dirty (modified). Evicting clean data is relatively straightforward: just delete them from memory (I’m hand-waving here but you get the idea ). Evicting dirty data is more involved, since it needs to ensure that all data are persisted to disk before it can be evicted.
This is more or less a universal term across databases. I think MySQL call this a buffer pool with similar ideas and working conditions.
During our performance test, I could not observe eviction-related messages in the mongo logs.
This is because this metric is WiredTiger specific and not MongoDB specific. It’s internal to WiredTiger, but you can see some statistics from db.serverStatus().wiredTiger.cache
How to simulate cache eviction?
Try to push a workload that’s larger than the available RAM on the machine. However this is a very generalized answer.
Having said that, I’m sure you understand that performance testing is a tricky subject that involves a lot of variables: server size, MongoDB configuration, WiredTiger configuration, hardware configuration, specific workload (insertion rate, update rate, read rate, delete rate, etc.), data size, index size, statistical distribution of the data, and many other things that needs to be considered to make sure that tests are repeatable and representative, so I don’t believe there’s a one-size-fits-all question or answer to this complex endeavour