ASP.NET Benchmarks: the harness the ASP.NET team measures its own runtime with

What the repository actually contains: apps, images and scenario definitions

The repository is a set of benchmark applications and Docker images rather than a single runnable program, and the README says they work best with Microsoft Crank, pointing readers at the Crank repository for instructions on running them on their own machines. The top level layout explains the structure. The src/ directory holds the application sources, docker/ holds the container definitions, scenarios/ holds the scenario definitions and the sample command lines for Crank, build/ holds the pipeline generation mapping, scripts/ holds helper tooling, and .azuredevops/ plus azurepipeline-pr.yml hold the pipeline definitions. There is also a NuGet.Config, a global.json and an es-metadata.yml. The README describes the contents as benchmarks for ASP.NET Core, including but not limited to scenarios from the TechEmpower Web Framework Benchmarks, so the scenarios that people recognise from elsewhere are a subset rather than the whole set.

Tracked results live on a Microsoft site, not in the repository

The README does not contain a single benchmark result. Instead it says the current results tracked by the ASP.NET team are available at a short link, aka.ms/aspnet/benchmarks. That distinction matters more than it first appears. A repository that ships results would give you numbers whose provenance you would have to trust and whose environment you could not inspect. Here, the artifacts you get are the applications and the images, and the tracked numbers are published separately by the team that runs them continuously. If your question is what ASP.NET Core scores against another framework, this repository is where the method lives rather than where the answer is printed, and the answer depends on the harness settings, the machine and the scenario.

Crank is the harness, and the scenarios directory is the entry point

Nothing here runs on its own. The benchmark applications and the Docker images are designed to be driven by Microsoft Crank, and the README states plainly that the scenarios available to use with Crank, along with some sample command lines, are on the scenarios page. That makes the scenarios directory the practical starting point for anyone new to the project, because each scenario is a defined workload with a sample command line. The division of labour follows from how the project is used: Crank runs the benchmarks, while this repository owns what is being measured. A reader who wants to know how a scenario behaves, which endpoints it hits, or how many connections it opens will find that in the scenario definition rather than in the README, which stays deliberately short.

No install command in the README: the setup path points at Crank

There is a point worth being blunt about, because it is a common trip hazard. The README contains no dotnet commands, no restore step, no benchmark invocation of its own, and no configuration snippet. The setup section exists only to say that these applications and images work best with Crank and that you should follow the instructions in the Crank repository to run them on your own machines. If you are looking for a one line install, there is not one, and writing one here would be inventing it. What you do need in practice follows from the design: a working.NET SDK matching the global.json pin, Docker for the images, and Crank installed separately, since the scenarios are meant to be run with Crank. The README is a signpost, and the signpost points outside the repository.

The daily pipeline is generated from JSON, and the pod scheduler is the reason

The continuous benchmarking pipelines are not hand written YAML. The README states that the Azure DevOps pipelines driving the daily benchmark sweep are generated from JSON configs by the pod-scheduler, whose own documentation lives under scripts/pod-scheduler. The build/README.md file maps configs to the generated YAML files and explains how to regenerate them after editing. This is a design decision with real consequences for anyone who wants to change the sweep. The source of truth is a config, the generated YAML is an artefact, and a hand edit to the YAML will be replaced the next time the generator runs. The repository also has a .config/ directory and a .github/ directory at the top level, and a separate azurepipeline-pr.yml alongside the main pipeline set, which suggests pull request validation is wired in separately from the daily sweep.

Contribution is limited to a Microsoft approval team, which shapes what the repo is for

The contributing section is short and unusual. It says that Microsoft employees can approve and merge contributions by joining a named team on the Microsoft Open Source site, and that is the entire instruction. There is no general pull request pathway described for outside contributors, and no statement about how external changes would be reviewed. A benchmark repository is not usually the place where product code lives, but this constraint tells you what kind of project it is: a measurement instrument maintained by the team whose runtime is on the measuring table. That shape also explains the daily sweep and the published tracking site. The repository carries the usual community files, a CODE-OF-CONDUCT.md, a CONTRIBUTING.md and a SECURITY.md, and the licence is a custom one in LICENSE.txt that GitHub does not classify, so anyone reusing the scenario code should read that file rather than assume a standard open source grant.

Maintenance: an active repository with no releases, and an upstream comparison to calibrate against

The last push to the repository was on 2026-10-14, so the work is current, and the repository is not archived. There are no GitHub releases, which fits a project whose output is a moving set of images and scenarios rather than a versioned artefact you download. For anyone comparing this to alternatives, the honest comparison is with the TechEmpower Web Framework Benchmarks, which the README names as a source of scenarios. The difference in approach is that TechEmpower's benchmarks are a cross-framework comparison, while this repository is scoped to ASP.NET Core and is tuned for a continuous, unattended sweep on infrastructure the ASP.NET team controls. TechEmpower answers a broad question about where frameworks sit relative to each other; this one answers a narrow question about whether a change to ASP.NET Core moved a specific workload, which is a different job and a different audience.

Editorial conclusion

This repository suits a team that wants to measure its own ASP.NET Core deployment rather than quote somebody else's numbers, and that already has Docker and the patience to drive Crank across several machines. It is the wrong tool for a quick comparison of frameworks, for a laptop benchmark, or for any reader who wants a single headline figure, because the README points to tracked results rather than publishing them, and the results depend on the harness configuration you choose. Before running anything, read the instructions in the Crank repository as the README directs, pick a scenario from the scenarios directory, and check the mapping in build/README.md before regenerating anything, since the Azure DevOps pipelines are generated from JSON configs through the pod scheduler and editing the YAML by hand will be overwritten.

Frequently asked questions

Official sources

1. aspnet/Benchmarks on GitHub
2. Issues
3. README