| I'm wondering the same, but honestly I have a soft corner for the old way of doing things as well, and I think it stems from it. The performance numbers seem to show how bad it is in real world. For testing I converted the CGI script into a FastAPI script and benchmarked it on my MacBookPro M3. I'm getting super impressive performance numbers, Read
```
Statistics Avg Stdev Max
Reqs/sec 2019.54 1021.75 10578.27
Latency 123.45ms 173.88ms 1.95s
HTTP codes:
1xx - 0, 2xx - 30488, 3xx - 0, 4xx - 0, 5xx - 0
others - 0
Throughput: 30.29MB/s
```
Write (shown in the graph of the OP)
```
Statistics Avg Stdev Max
Reqs/sec 931.72 340.79 3654.80
Latency 267.53ms 443.02ms 2.02s
HTTP codes:
1xx - 0, 2xx - 0, 3xx - 13441, 4xx - 0, 5xx - 215
others - 572
Errors:
timeout - 572
Throughput: 270.54KB/s
``` At this point, the contention might be the single SQL database. Throwing a beefy server like in the original post would increase the read performance numbers pretty significantly, but wouldn't do much on the write path. I'm also thinking that at this age, one needs to go out of their way to do something with CGI. All macro, micro web frameworks comes with a HTTP server and there are plenty of options. I wouldn't do this for anything apart from fun. FastAPI-guestbook.py https://gist.github.com/rajaravivarma-r/afc81344873791cb52f3... |