WcfPerformanceLab

WcfPerformanceLab is a local benchmark harness for comparing the request/response performance of external Legacy WCF and CoreWCF service hosts.

WcfPerformanceLab does not contain the measured hosts. It benchmarks external local Legacy WCF and CoreWCF applications through configured endpoints.

The aim is not to assume CoreWCF is faster. The aim is to produce objective, repeatable evidence using the same contract, client, payload, implementation behaviour, load profile, server metric conditions, and reporting format.

The shared contract boundary is WcfPerformanceLab.Contracts, which should be used by the benchmark client and, where possible, by both external measured hosts.

Primary comparison

Legacy WCF host
.NET Framework 4.6 / 4.7
System.ServiceModel server hosting

vs

CoreWCF host
.NET Framework 4.8
SDK-style project
CoreWCF NuGet packages

If possible, also add:

Legacy WCF on .NET Framework 4.8
vs
CoreWCF on .NET Framework 4.8

That removes the framework-version difference and gives a cleaner hosting-stack comparison.

What is being measured?

The project measures the WCF request/response pipeline:

client
  -> System.ServiceModel client proxy
  -> endpoint transport
  -> server WCF/CoreWCF pipeline
  -> service operation
  -> response serialization
  -> client receives response

The main comparison is:

System.ServiceModel server hosting pipeline
vs
CoreWCF server hosting pipeline

Metrics captured

For each measured run, the harness captures:

request attempts
successes
failures
timeouts
successful requests per second
minimum, average, p50, p95, p99, and maximum successful latency

When local server-process monitoring is configured, the harness also samples the external target process during the measured phase:

normalised process CPU percentage
private memory
working-set memory
thread count
process uptime

The result retains raw request timings, raw process samples, and their aggregated summaries. The performance-test file writer can persist the selected outputs as Markdown, CSV, JSON, a request-timings CSV, and a server-process-metric-samples CSV.

Process metrics are optional. To enable them:

• supply an IServerProcessMetricCollector to BenchmarkRunner;
• supply ServerProcessMetricOptions in BenchmarkRunRequest;
• configure BenchmarkTarget.ProcessName;
• ensure exactly one matching local process is running.

Process collection starts after warm-up and stops when the measured phase finishes.

Responsibility boundaries

WcfPerformanceLab.Benchmarking
    controls warm-up, measurement, and metric-collection lifetime

WcfPerformanceLab.Metrics
    captures and aggregates request and server-process measurements

WcfPerformanceLab.Reporting
    formats Markdown and CSV summaries, the complete JSON result,
    raw request-timing CSV, and raw server-process-sample CSV

WcfPerformanceLab.Performance.Tests
    runs intentional benchmarks and writes the selected result files

What is not being measured?

The benchmark should avoid unstable external work such as:

• database query performance;
• real external API latency;
• third-party network variability;
• business logic differences;
• different payloads or bindings;
• different client code paths.

Where required, real external dependencies should be replaced by deterministic fakes or stubs.

The current process collector does not measure remote hosts, garbage-collection counts, managed heap sizes, handle counts, or total machine CPU usage.

Documentation

Detailed documentation lives under docs/:

docs/project-structure.md
docs/contract-strategy.md
docs/benchmark-methodology.md
docs/benchmarkrunner-explanation.md
docs/metrics-and-reporting.md
docs/metrics-interpretation-guide.md
docs/local-development.md