DynamicBenchmarker is composed with two programs,
DynamicBenchmarker.master and
servants. The master program creates
multiple servant programs, and the servant programs execute the prefixed
functions in parallel. When the pre-congirued count of requests are all
completed, the master program collects the results and returns them.
Additionally, if you hope to see some utilization cases, see the below
example tagged links.
Processing cost: Totals are split across T servants once; E events are
aggregated with hash-based endpoint grouping. Progress notifications update
the aggregate from one servant counter delta in constant time. Event
statistics and rendering traverse their input populations; discovery visits
each real directory once.
Computation reuse: A master distributes distinct request budgets rather than
replaying one effectful request. Endpoint grouping shares one event
population across whole-run and endpoint statistics. Results are not cached
across benchmark runs because server state and timing change.
Resource ownership: Each master owns at most threads connectors and
simultaneous function workers; connector closure is attempted on
connection/execution success or failure; a rejected close is suppressed and
may leave an unreleased child process. Events retained by servants/master
scale with logged events, and memory samples with run duration. The
independent sampler detaches its report target on stop or rejection and
clears/wakes its owned timer. A pending caller memory getter has no
cancellation hook, but its task retains only the sampler state/getter and
cannot keep the master report arrays, connectors or event collections through
that state. Its eventual result is discarded after deactivation. Returned
reports transfer their arrays to callers.
Platform boundary: WorkerConnector process mode owns Node child-process
launch/IPC and its explicit stdio modes. Feature discovery resolves the
caller location with native path and fs realpath/stat, follows directory
links with realpath cycle detection and imports discovered native absolute
paths. It does not infer filesystem case policy from OS names.
contracts/common.md#principled-implementation The master spawns one child process per thread through tgrid's process-mode WorkerConnector, drives each servant over RPC, and merges the returned events; totals are split by floor plus remainder so the shares sum to the requested count and simultaneous budget.
Evidence
contracts/common.md#clear-and-simple-design One namespace is the public surface (master, servant, markdown, props, report); execution, discovery, and cleanup helpers stay private, and statistics and rendering live in their own internal namespaces.
Evidence
contracts/common.md#prohibited-implementation-shortcuts Nothing names a server, feature, or file: the feature extension, prefix, and filter are caller inputs, and the servant path is a property rather than an assumed location.
Evidence
contracts/common.md#meaningful-documentation The namespace prose explains the two-program model, what each program does, and how to obtain markdown, with links to the member documentation and to example repositories.
Dynamic benchmark executor running prefixed functions.
DynamicBenchmarkeris composed with two programs, DynamicBenchmarker.master and servants. The master program creates multiple servant programs, and the servant programs execute the prefixed functions in parallel. When the pre-congirued count of requests are all completed, the master program collects the results and returns them.Therefore, when you want to benchmark the performance of a backend server, you have to make two programs; one for calling the DynamicBenchmarker.master function, and the other for calling the DynamicBenchmarker.servant function. Also, never forget to write the path of the servant program to the DynamicBenchmarker.IMasterProps.servant property.
Also, you when you complete the benchmark execution through the DynamicBenchmarker.master and DynamicBenchmarker.servant functions, you can convert the result to markdown content by using the DynamicBenchmarker.markdown function.
Additionally, if you hope to see some utilization cases, see the below example tagged links.
Processing cost: Totals are split across T servants once; E events are aggregated with hash-based endpoint grouping. Progress notifications update the aggregate from one servant counter delta in constant time. Event statistics and rendering traverse their input populations; discovery visits each real directory once.
Computation reuse: A master distributes distinct request budgets rather than replaying one effectful request. Endpoint grouping shares one event population across whole-run and endpoint statistics. Results are not cached across benchmark runs because server state and timing change.
Resource ownership: Each master owns at most threads connectors and simultaneous function workers; connector closure is attempted on connection/execution success or failure; a rejected close is suppressed and may leave an unreleased child process. Events retained by servants/master scale with logged events, and memory samples with run duration. The independent sampler detaches its report target on stop or rejection and clears/wakes its owned timer. A pending caller memory getter has no cancellation hook, but its task retains only the sampler state/getter and cannot keep the master report arrays, connectors or event collections through that state. Its eventual result is discarded after deactivation. Returned reports transfer their arrays to callers.
Platform boundary: WorkerConnector process mode owns Node child-process launch/IPC and its explicit stdio modes. Feature discovery resolves the caller location with native path and fs realpath/stat, follows directory links with realpath cycle detection and imports discovered native absolute paths. It does not infer filesystem case policy from OS names.
Author
Jeongho Nam - https://github.com/samchon
Example
Example
Evidence
contracts/common.md#principled-implementation The master spawns one child process per thread through tgrid's process-mode
WorkerConnector, drives each servant over RPC, and merges the returned events; totals are split by floor plus remainder so the shares sum to the requested count and simultaneous budget.Evidence
contracts/common.md#clear-and-simple-design One namespace is the public surface (master, servant, markdown, props, report); execution, discovery, and cleanup helpers stay private, and statistics and rendering live in their own internal namespaces.
Evidence
contracts/common.md#prohibited-implementation-shortcuts Nothing names a server, feature, or file: the feature extension, prefix, and filter are caller inputs, and the servant path is a property rather than an assumed location.
Evidence
contracts/common.md#meaningful-documentation The namespace prose explains the two-program model, what each program does, and how to obtain markdown, with links to the member documentation and to example repositories.