As @Andrew_Morrow mentioned,
mongoperf was specific to the original MMAPv1 storage engine which was deprecated in MongoDB 4.0 and removed in MongoDB 4.2.
mongoperf ultimately only provided an estimated upper bound on I/O performance – actual outcomes are highly dependent on factors including your workload, deployment topology, and software versions. The most useful aspect of this tool was confirming there were no egregious MMAP performance issues with your environment, but it wasn’t an indicative measure of query performance.
There are generic and more comprehensive tools like
fio for general I/O comparisons, but it is difficult to extrapolate these outcomes to database workloads that go through a much more complex execution path.
You can use load testing tools like JMeter to test concurrency and performance with your application stack and deployment configuration. This category of tools is not specific to MongoDB.
There are also Application Performance Monitoring (APM) platforms like New Relic and DataDog that facilitate full stack monitoring and can be helpful for visualising and correlating issues in your application code, database deployment, and frontend experience.
The default WiredTiger storage engine applies changes in memory with periodic durability via journaling and checkpoints, so this is a likely starting point for your use case.
The In-Memory Storage Engine available in MongoDB Enterprise intentionally avoids disk I/O and requires that all data and indexes fit in memory. The use case for this storage engine is workloads requiring more predictable latency. If you want to add persistence you can deploy a replica set with In-Memory members as well as a hidden WiredTiger member configured to write to disk per In-Memory Deployment Architectures.
This is going to be very workload dependent, but I would start by profiling your workload to understand where your actual bottlenecks are. Starting with server source code modifications is generally premature optimisation. I would try improving concurrency rather than increasing the memory usage per socket.
In one of your previous discussion topics (Mongodb interface for high speed updates) you mentioned wanting to write directly to data files. If you use WiredTiger directly as a local database library you can avoid any overhead of network stack or higher level query abstractions. I feel like that path is better aligned with the low level approach you are trying to take.