[SERVER-21014] benchRun() does not report premature worker termination as an error Created: 19/Oct/15  Updated: 06/Dec/22  Resolved: 11/May/20

Status: Closed
Project: Core Server
Component/s: Performance, Shell
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: J Rassi Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: benchRun, benchrun-intern, dmd_old_benchrun, tig-benchrun
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-22798 benchRun doesn't properly detect and ... Closed
Assigned Teams:
Server Tooling & Methods
Operating System: ALL
Participants:

 Description   

There are a number of error paths in benchRun() that throw exceptions (e.g. if the request was malformed, if the "expected" option to find did not match the size of the query result set). By default, these exceptions cause the worker thread to terminate early; however, no error is reported in the result of the benchRun() call.

For example, the following script terminates the worker thread early (because the size of the query result set does not match the expected value), and shows that the benchRun() call returns success and that the "errCount" value is unchanged:

db.foo.drop();
var res = benchRun({ops: [{op: "find", query: {}, ns:"test.foo", expected: NumberInt(1)}], seconds: 3});
assert.gt(res.errCount, 0);  // Unexpected: does not trip.



 Comments   
Comment by Ryan Timmons [ 11/May/20 ]

Closing as wont-fix to indicate that there is currently no intention of doing this. Please re-open if there is priority for this. Perhaps this change could self-service by an appropriate server team if this is necessary rather than having to go thru the STM prioritization queue.

Comment by April Schoffer [ 16/Nov/18 ]

max.hirschhorn Moving these benchrun tickets over from PERF for your review and prioritization.

Comment by Ian Whalen (Inactive) [ 18/Feb/16 ]

CC martin.bligh

Generated at Thu Feb 08 03:55:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.