HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
TechEmpower
FrameworkBenchmarks
C++2013–2026
TechEmpower / FrameworkBenchmarks · Archived

FrameworkBenchmarks

Source for the TechEmpower Framework Benchmarks project

143Distinct people
247Mentions
3Explicit recommenders
8.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Source for the TechEmpower Framework Benchmarks project

GitHub

Where it is used

  • ASP.NET Core — ASP.NET Core used the TechEmpower Framework Benchmarks as a focus for performance work. Microsoft prioritized improving ASP.NET’s performance in these benchmarks. Source
  • Benchmarks for ASP.NET Core — Benchmarks for ASP.NET Core includes scenarios from the TechEmpower Web Framework Benchmarks in its benchmarking suite. Source

What people are saying

Sorry, I should have been more precise. I am very, very familiar with the TechEmpower benchmarks and I first learned Java around SE 5, right after they switched from 1.x…

AaronFriel used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year247 dated mentions

Observed mentions: 2013-03-28 15:05:31 UTC to 2026-03-24 12:37:38 UTC.

02550751002013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 106 mentions; 2 submissions, 104 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 20 mentions; 0 submissions, 20 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 25 mentions; 0 submissions, 25 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 15 mentions; 0 submissions, 15 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC1062104
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC20020
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC808
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC808
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC909
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC10010
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC14014
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC25025
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC14014
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC15015
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC817
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC422

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Welcome to TechEmpower Framework Benchmarks (TFB) If you're new to the project, welcome! Please feel free to ask questions here. We encourage new frameworks and contributors to ask questions. We're here to help! This project provides representative performance measures across a wide field of web application frameworks. With much help from the community, coverage is quite broad and we are happy to broaden it further with contributions. The project presently includes frameworks on many languages including Go, Python, Java, Ruby, PHP, C#, F#,Clojure, Groovy, Dart, JavaScript, Erlang, Haskell, Scala, Perl, Lua, C, and others. The current tests exercise plaintext responses, JSON serialization, database reads and writes via the object-relational mapper (ORM), collections, sorting, server-side templates, and XSS counter-measures. Future tests will exercise other components and greater computation. Read more and see the results of our tests on cloud and physical hardware. For descriptions of the test types that we run, see the test requirements section. If you find yourself in a directory or file that you're not sure what the purpose is, checkout our file structure in our documentation, which will briefly explain the use of relevant directories and files. Quick Start Guide To get started developing you'll need to install docker or see our Quick Start Guide using vagrant Clone TFB. $ git clone https://github.com/TechEmpower/FrameworkBenchmarks.git Change directories $ cd FrameworkBenchmarks Run a test. $ ./tfb --mode verify --test gemini Explanation of the ./tfb script The run script is pretty wordy, but each and every flag is required. If you are using windows, either adapt the docker command at the end of the ./tfb shell script (replacing ${SCRIPT_ROOT} with /c/path/to/FrameworkBenchmarks), or use vagrant. The command looks like this: docker run -it --rm --network tfb -v /var/run/docker.sock:/var/run/docker.sock -v [FWROOT]:/FrameworkBenchmarks techempower/tfb [ARGS] -it tells docker to run this in 'interactive' mode and simulate a TTY, so that ctrl+c is propagated. --rm tells docker to remove the container as soon as the toolset finishes running, meaning there aren't hundreds of stopped containers lying around. --network=tfb tells the container to join the 'tfb' Docker virtual network The first -v specifies which Docker socket path to mount as a volume in the running container. This allows docker commands run inside this container to use the host container's docker to create/run/stop/remove containers. The second -v mounts the FrameworkBenchmarks source directory as a volume to share with the container so that rebuilding the toolset image is unnecessary and any changes you make on the host system are available in the running toolset container. techempower/tfb is the name of toolset container to run A note on Windows Docker expects Linux-style paths. If you cloned on your C:\ drive, then [ABS PATH TO THIS DIR] would be /c/FrameworkBenchmarks. Docker for Windows understands /var/run/docker.sock even though that is not a valid path on Windows, but only when using Linux containers (it doesn't work with Windows containers and LCOW). Docker Toolbox may not understand /var/run/docker.sock, even when using Linux containers - use at your own risk. Quick Start Guide (Vagrant) Get started developing quickly by utilizing vagrant with TFB. Git, Virtualbox and vagrant are required. Clone TFB. $ git clone https://github.com/TechEmpower/FrameworkBenchmarks.git Change directories $ cd FrameworkBenchmarks/deployment/vagrant Build the vagrant virtual machine $ vagrant up Run a test $ vagrant ssh $ tfb --mode verify --test gemini Add a New Test Either on your computer, or once you open an SSH connection to your vagrant box, start the new test initialization wizard. vagrant@TFB-all:~/FrameworkBenchmarks$ ./tfb --new This will walk you through the entire process of creating a new test to include in the suite. Resources Official Documentation Our official documentation can be found in the wiki. If you find any errors or areas for improvement within the docs, feel free to open an issue in this repo. Live Results Results of continuous benchmarking runs are available in real time here. Data Visualization If you have a results.json file that you would like to visualize, you can do that here. You can also attach a runid parameter to that url where runid is a run listed on tfb-status like so: https://www.techempower.com/benchmarks/#section=test&runid=fd07b64e-47ce-411e-8b9b-b13368e988c6. If you want to visualize them or compare different results files on bash, here is an unofficial plaintext results parser Contributing The community has consistently helped in making these tests better, and we welcome any and all changes. Reviewing our contribution practices and guidelines will help to keep us all on the same page. The contribution guide can be found in the TFB documentation. Join in the conversation in the Discussions tab, on Twitter, or chat with us on Freenode at #techempower-fwbm.
Read the full README on GitHub

What Hacker News says

15 sources
Instead of putting together ad-hoc benchmarks, it would be preferable if Bun is compared with the same benchark tests already used by other frameworks, such as the TechEmpower benchmark. https://github.com/TechEmpower/FrameworkBenchmarks/discussio... This would eliminate any funny business with benchmarks, such as comparing suboptimal implementations of other tech stacks with our own finely tuned custom implementation, and proceed to run it in a cherry-picked test.
In Go vs. Rust vs. Bun vs. Node, Simple HTTP Benchmark
Since you mentioned them I think it's worth telling people to take those benchmarks with a larger grain of salt. They've become such a pissing contest that I don't know if they can be called "real-world". There doesn't seem to be much scrutiny of the implementations. Take some Rust frameworks: they write out pre-computed header strings to the output buffer, completely bypassing what the framework's documentation recommends. Examples are actix[1] and ntex[2]. No one would ever do this in real life. Now I like Rust, and it'd likely be some of the fastest even without these shenanigans (Axum and may-http don't do that, I believe). But I don't know if other languages/frameworks have benchmarks implemented in the same non-idiomatic way just to look better. [1] - https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [2] -https://gith
Read the rest
In Elixir saves Pinterest $2M a year in server costs
I've only skimmed some of the code, but fwiw, anyone can read their code for each framework that's benchmarked here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... There's also a good amount of active discussion going on here: https://github.com/TechEmpower/FrameworkBenchmarks/discussio... Here's the code for the JS (just-js) benchmark: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... And here's the code for the Python uvicorn benchmark: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... From some light skimming, the JS and Python code doesn't look particularly abnormal or overly-optimized.
In Elixir saves Pinterest $2M a year in server costs
Well, perhaps not 100x in rps, but 10x sure: Overall top performing frameworks (JS, Java, and Rust) at 650K rps. That's 7x over the top Python based framework at: 86K rps. And another very popular Python framework (flask) gets just to 2K rps. That's 325 times worse to the best. And that's the "single DB query" benchmark: https://www.techempower.com/benchmarks/#section=data-r21&tes... https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Proj...
In Python-based compiler achieves orders-of-magnitude speedups
> And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way! As I wrote elsewhere [1], Dockerfiles are not deterministic. The build artifacts that they produce are deterministic, but that would be comparing a build artifact to a build system. > There is another similar ecosystem of mobile apps. That's also way superior in terms of the developer experience. Mobile app users have different performance expectations. No one bats an eye if a mobile app takes several minutes to download/update, but a website that does so would be considered an atrocity. > And that's not what I am objecting to. M
Read the rest
y concern is that the core JS specification is so barebones that it fragments right from the start. JS is actually really well specified by ECMA. There are so many languages where the formal specification is "whatever the most popular compiler outputs". > You make different choices and soon every single JS project looks drastically different from every other project. The same could be said of any other moderately complex project written in a different language. Look at the Techempower benchmarks for Java, and tell me those projects all look identical [2]. > 1. There isn't a standard project format 2. There isn't a single framework that's backward compatible for 5+ years. 3. There isn't even an agreeement on the right build tools (npm vs yarn vs pnpm...) 4. There isn't an agreement on how to do multi-threaded async work A lot of the complexity you're describing stems from running in the browser. A server-side js project that returns plain html with a standard templating language is remarkably stable. Express has been on version 4.x.x for literally 9 years [3]. Package.json is supported by yarn, npm, and pnpm. As long as you have a valid lock file and install dependencies using npm ci, you really shouldn't have too many issues running most js projects. I'm not sure what issues you've had with multi-threaded async. The standard for multi-threading in js is web workers (which are called worker threads in node). The js ecosystem is not like Scala or Rust, where's there's tokio and akka. JS uses promises for concurrency, and workers for parallelism. [1] https://news.ycombinator.com/item?id=35002815 [2]https://github.com/TechEmpower/FrameworkBenchmarks/tree/9844... [3] https://www.npmjs.com/package/express/v/4.0.0
In You don't need a build step
In the TechEmpower benchmarks, Clojure is about 2.75x slower than Java, while Python is 5.59x slower. The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%. https://www.techempower.com/benchmarks/#section=data-r21&l=z... About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation): https://www.techempower.com/benchmarks/#section=data-r21&l=z... I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to
Read the rest
In I still Lisp (2021)
Actually uWebSockets and uSockets will perform better than this (2x at least in my local tests), I need to do a lot of copying, instancing and crossing Python GIL. Yeah this test basically shows that Python backed by uWS is crazy fast, but is not an direct comparison to uWS to Go. This test is just an troughput test, with is very useful to measure raw performance. More tools like caching tools, a better database client etc is need to construct an complete scenario, and i'm working on it! (Maybe in 1 week or 2 weeks will be done) https://github.com/TechEmpower/FrameworkBenchmarks https://www.techempower.com/benchmarks/#section=test&runid=1...
In Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
Python framework because is an framework for python, like most performance focused frameworks for python, this uses a lot of native code. uvicorn uses uvloop that is an wrapper for libuv. Web developer dont care if the framework is written in native or it is an wrapper, developers just want something that works in a nice way :D The benchmarks are in https://github.com/TechEmpower/FrameworkBenchmarks EDIT: some preliminary results https://www.techempower.com/benchmarks/#section=test&runid=1...
In Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.