Parallel insert performance test shows that writes with { w: majority, j: false } perform worse than { w: majority } which enabled journaling by default.

        {
          "end": 1606114697.135247,
          "name": "ParallelInsert-1-Insert_WMajority_JFalse",
          "results": {
            "1": {
              "ops_per_sec": 315.3323923270361,
              "ops_per_sec_values": [
                315.3323923270361
              ]
            }
          },
          "start": 1606112991.5566537,
          "workload": "genny"
        },
...
        {
          "end": 1606114697.135247,
          "name": "ParallelInsert-1-Insert_WMajority",
          "results": {
            "1": {
              "ops_per_sec": 373.07617520622085,
              "ops_per_sec_values": [
                373.07617520622085
              ]
            }
          },
          "start": 1606112991.5566537,
          "workload": "genny"
        },

I found this issue using an update workload in my paper experiments against 4.4.2 in a 5-node setting. It's weird that the latency is about 100ms for some operations even when there's just one client. This seems related to the default  storage.journal.commitIntervalMs used by the journal flusher

After I changed writeConcernMajorityJournalDefault to false, { w: majority } starts to perform as expected.

As a comparison, the default setting with { writeConcernMajorityJournalDefault: true } and { w: majority } gives a lower but comparable throughput as expected.

My theory is that the code missed signaling writers when updating the positions because it is conditional on writeConcernMajorityJournalDefault.