Compute client waiting time without including testing framework time #50
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, the time to stop node threads and the time to check invariants was charged against any outstanding client requests' waiting time. Stopping a node thread requires that the node thread finish executing the current event handler. If the event handler has a performance bug, that will cause
runstate.stop()
to be slow. Similarly, checking invariants can be expensive for long logs.This commit introduces markEndTimeOfOutstandingRequest, which allows the test to set the ending time of outstanding requests before stopping threads and checking invariants. Then, after those (potentially expensive) operations, the tests can assert that the waiting time is acceptable.
Unfortunately this introduces a bit of a sharp corner into the testing framework's internal API: it would be easy to forget to call markEndTimeOfOutstandingRequest before assertMaxWaitTimeLessThan. Perhaps we should add a check for this to help with framework maintenance.
I also added a warning if the framework detects that
runstate.stop()
took longer than one second. That indicates that some event handler in the system took a long time to run. (This warning remains difficult to debug, but at least the new situation is better than the previous one.)