Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-21145

Improve performance of "readCmd: true" find operations in benchRun()

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Performance, Shell
    • None

    Description

      For a find-by-id workload in benchRun() with the "readCmd: true" option set, a significant amount of CPU time is spent in benchRun() parsing the user request object and parsing the server command response. This can cause the report of latency and throughput numbers for these workloads to be misleading.

      This can be improved as follows:

      • The user request object should be serialized only once, at the beginning of the worker's lifetime.
      • The "findOneCounter" and "queryCounter" counter objects should be recording only the time spent in runCommand() (not the time spent serializing the request or parsing the response).
      • A lighter-weight version of CursorResponse should be used which avoids copying all of the returned objects into a std::vector<>.

      See the following script, which illustrates the difference in single-threaded find performance when switching from benchRun's "command" op to benchRun's "find" op with read commands:

      var coll = db.bench_test_crud_commands;
      coll.drop();
      coll.insert({_id: 1});
       
      var benchOps = [{ns: coll.getFullName(),
                       op: "find",
                       query: {},
                       batchSize: NumberInt(10),
                       readCmd: true}];
      var res = benchRun({ops: benchOps, parallel: 1, seconds: 5, host: db.getMongo().host});
      print("average latency in microseconds with find op: " + res.queryLatencyAverageMicros);
       
      benchOps = [{ns: coll.getDB().getName(),
                   op: "command",
                   command: {find: coll.getName(), filter: {_id: 1}}}];
      res = benchRun({ops: benchOps, parallel: 1, seconds: 5, host: db.getMongo().host});
      print("average latency in microseconds with commands op: " + res.commandsLatencyAverageMicros);
      

      See the following example run of the above script on my local machine, against a standalone deployment of latest master (6c5fb5a6). This run shows "find" as performing 12% slower than "commands".

      MongoDB shell version: 3.2.0-rc1-pre-
      connecting to: test
      average latency in microseconds with find op: 135.96427833987198
      average latency in microseconds with commands op: 119.65279813209469
      

      Attachments

        Activity

          People

            Unassigned Unassigned
            rassi J Rassi
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: