msquic icon indicating copy to clipboard operation
msquic copied to clipboard

Add 'delay' Option to SecNetPerf Server

Open nibanks opened this issue 4 years ago • 0 comments

Describe the feature you'd like supported

Currently, secnetperf server side immediately responds to incoming stream data requests from the peer (inline). This does a great job of measuring the best possible case scenario, and gives us an idea of the upper bounds of maximum achievable performance. The problem though, is that it doesn't practically mimic a real application's behavior. Perhaps in some cases an app might have cached data it can immediately return inline, but most of the time I expect the app to queue work to its own thread and only when that's complete, send the response back to the client.

In order to support mimicking a more realistic app behavior, we should add a new command line option delay that allows the user to specify a time (in microseconds) that the server should execute "work" on it's own thread before queuing the necessary response.

Proposed solution

Practically, this will entail the following changes:

  1. A new parameter (delay) that defaults to zero but can be overwritten at command line.
  2. If delay is non-zero, the perf server creates per-processor worker threads.
  3. On receipt of a stream (just ones that request app data?), if delay is non-zero queues a "work item" to the worker threads. a. When the work item executes it runs "does work" (sit in a loop running calling CxPlatTimeUs64()) for the delay time. b. Then it queued the data on the stream

Synchronization of the work and a stream/connection possibly getting shutdown might be a bit tricky.

nibanks avatar Apr 27 '21 17:04 nibanks