Python, CSharp, Go, Next.js: How Much Do Different Frameworks Really Differ in Performance?

Preface

It's December before I knew it. Too many odds and ends lately, so output hasn't been high. I'll keep organizing some recent notes.

Last time I compared different servers used when deploying the Django framework; details: Performance Research on Different Django Servers and Deployment Methods

While exploring, I also ran comparison tests on frameworks in different languages.

Django Test Follow-up

A few extra conclusions from the last Django performance test:

• drf and ninja don't differ much in performance
• On a 2C2G server, workers=4 performs better than workers=2. As for how much better, I only tested the uwsgi server, and the gap is about 33%

This Test

Languages and frameworks in this test:

• aspnetcore 8.0 (starblog project)
• aspnetcore webapi(controller) 9.0 (ayaka-chats project)
• go + gin (ebook-forge project)
• Next.js (iothub dashboard project)

To keep variables under control, I deployed a copy of each of these projects on a Tencent Cloud 2C2G thin-pipe server and tested them together.

The test command was the same throughout:

wrk -t4 -c200 -d30s <url>

The test targets were all lightweight APIs in each project (returning a short string or simple JSON), focusing on the framework's own throughput and latency rather than business-code complexity.

Test Conclusions

The results are pretty interesting, and they largely match how these frameworks have felt to me over long-term use.

Overview

By the way, Django's best result last time was around 1200RPS. Recap: Performance Research on Different Django Servers and Deployment Methods

Conclusions

1. Overall performance champion: AspNetCore 9

Highest throughput, moderate memory, strong ecosystem. Suited to future large projects (e.g. the Clipify editor, AI services, Chat API).

2. Lightweight champion: Go + Gin

Lowest memory use, cheapest to deploy and scale. Suited to standalone components or internal services.

3. The reality of traditional web projects: AspNetCore MVC is too heavy

Migrating old projects is costly, but new projects really shouldn't keep using MVC.

4. Node.js/Next.js is not suited to high-concurrency APIs

Fine for frontend pages and simple backend logic, but not as a performance core.

Item-by-item Analysis

AspNetCore 8.0 MVC (StarBlog)

“The old project is holding it back. The performance hit is mainly from the architecture, not .NET itself.”

Memory shot straight up to 560MB, which means:

• All kinds of IOC + MVC + middleware maxed out
• The project structure itself is bloated
• Throughput under 6k RPS

AspNetCore 9.0 WebAPI (Ayaka Chats)

“This is Microsoft showing its real strength.”

• Memory only 80M, very clean and lean.
• 15k RPS is the champion here.
• CPU can be fully utilized, meaning the framework isn't the bottleneck and can squeeze the machine dry.

✔ Suited to high-performance microservices and AI relay services

✔ Suited to AI SaaS and personal-tool API scenarios

⚠ The person writing it needs to know C#

Go + Gin (Ebook Forge)

“Extremely lightweight, but throughput this time wasn't that impressive.”

• Memory only 35M, ridiculously light.
• Throughput 6k RPS, a bit lower than I expected, but stable.
• CPU only at 70%, showing the Go scheduler is steady, but Gin itself didn't fully saturate the CPU.

✔ Especially suited to background queues, message processing, and lightweight services

✔ Suited to cost-sensitive deployment scenarios (small-memory machines)

✘ For developers leaning full-stack + AI, the ecosystem is relatively weaker

Next.js (iothub dashboard)

“Node running APIs: it can run, but don't expect high concurrency.”

• 400 RPS → not an API performance framework (you'd expect the thousand-RPS range of Express/fastify)
• Latency 200ms+ → once again confirms Node.js's single-thread + V8 characteristics
• Suited to SSR/frontend BFF, not as a primary API

✔ If it's page rendering or frontend services, it's decent

✘ If APIs are the main battlefield, don't put it through that

Test Data

aspnetcore 8.0 (starblog project)

Peak memory during the test was around 560M, CPU at 100%; This project is AspNetCore MVC plus a relatively old architecture, so it's bloated, uses a lot of memory, and performance is relatively poor.

$ wrk -t4 -c200 -d30s http://127.0.0.1:9874/Api/DataWrapperTest/StringResult
Running 30s test @ http://127.0.0.1:9874/Api/DataWrapperTest/StringResult
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    44.04ms   44.20ms 304.43ms   88.08%
    Req/Sec     1.59k   559.31     2.42k    75.64%
  179013 requests in 30.03s, 44.22MB read
Requests/sec:   5960.51
Transfer/sec:      1.47MB

aspnetcore webapi(controller) 9.0 (ayaka-chats project)

Peak memory during the test was around 80M, CPU at 95%

$ wrk -t4 -c200 -d30s http://127.0.0.1:16080/api/auth/csrf
Running 30s test @ http://127.0.0.1:16080/api/auth/csrf
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.94ms    8.17ms 111.67ms   83.87%
    Req/Sec     3.78k     1.06k    5.68k    72.92%
  451205 requests in 30.02s, 99.40MB read
Requests/sec:  15031.56
Transfer/sec:      3.31MB

go + gin (ebook-forge project)

Peak memory during the test was around 35M, CPU at 70%

$ wrk -t4 -c200 -d30s http://127.0.0.1:8080/health
Running 30s test @ http://127.0.0.1:8080/health
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    37.13ms   33.65ms 499.93ms   82.09%
    Req/Sec     1.55k   328.35     2.86k    74.04%
  184447 requests in 30.02s, 114.86MB read
Requests/sec:   6145.14
Transfer/sec:      3.83MB

Next.js (iothub dashboard project)

Peak memory during the test was around 135M, CPU at 50%

$ wrk -t4 -c200 -d30s http://127.0.0.1:3000/api/health
Running 30s test @ http://127.0.0.1:3000/api/health
  4 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   251.98ms  110.23ms   1.95s    68.01%
    Req/Sec   112.01     89.28   515.00     61.88%
  12192 requests in 30.03s, 4.45MB read
  Socket errors: connect 0, read 0, write 0, timeout 118
Requests/sec:    405.96
Transfer/sec:    151.80KB

Wrap-up

For individual developers and lightweight SaaS:

If you want “satisfying” and “stable”, pick AspNetCore 9 first;

If you want “cheap” and “quick to pick up”, Go + Gin is great;

Django / Python has a strong ecosystem but performance isn't the main selling point; it depends on the ASGI server you choose;

Node.js is suited to BFF, not to carrying high-throughput APIs.