Serving a half billion requests per day with Rust and CGI
1–10 of 118 posts
Re: Serving a half billion requests per day with Rust and CGI
#2[deleted]
Re: Serving a half billion requests per day with Rust and CGI
#3How meaningful is “per day” as a performance metric?
Re: Serving a half billion requests per day with Rust and CGI
#4In a corporate environment, for internal use, I often see egregiously specced VMs or machines for sites that have very low requests per second. There's a commercial monitoring app that runs on K8s, 3 VMs of 128GB RAM each, to monitor 600 systems; using 500MB per system, basically, just to poll it each 5 minutes, do some pretty graphs, etc. Of course it has a complex app server integrated into the web server and so forth.
Re: Serving a half billion requests per day with Rust and CGI
#5I really like the code that accompanies this as an example of how to build the same SQLite powered guestbook across Bash, Python, Perl, Rust, Go, JavaScript and C: https://github.com/Jacob2161/cgi-bin
Re: Serving a half billion requests per day with Rust and CGI
#6I really like the code that accompanies this as an example of how to build the same SQLite powered guestbook across Bash, Python, Perl, Rust, Go, JavaScript and C: https://github.com/Jacob2161/cgi-bin
This is a veritable Rosetta stone of a repo. Wow.-
Re: Serving a half billion requests per day with Rust and CGI
#7How meaningful is “per day” as a performance metric?
Not at all, it may be a useful marketing metric, but not a performance one. The average load does not matter when your backend can't handle the peaks.
Re: Serving a half billion requests per day with Rust and CGI
#8Honestly, I'm just trying to understand why people want to return to CGI. It's cool that you can fork+exec 5000 times per second, but if you don't have to, isn't that significantly better? Plus, with FastCGI, it's trivial to have separate privileges for the application server and the webserver. The CGI model may still work fine, but it is an outdated execution model that we left behind for more than one reason, not just security or performance. I can absolutely see the appeal in a world where a lot of people are using cPanel shared hosting and stuff like that, but in the modern era when many are using unmanaged Linux VPSes you may as well just set up another service for your application server.
Plus, honestly, even if you are relatively careful and configure everything perfectly correct, having the web server execute stuff in a specific folder inside the document root just seems like a recipe for problems.
Re: Serving a half billion requests per day with Rust and CGI
#9Honestly, I'm just trying to understand why people want to return to CGI. It's cool that you can fork+exec 5000 times per second, but if you don't have to, isn't that significantly better? Plus, with FastCGI, it's trivial to have separate privileges for the application server and the webserver. The CGI model may still work fine, but it is an outdated execution model that we left behind for more than one reason, not j…
For smaller things, and I mean single-script stuff, I pretty much always use php-fpm. It’s fast, it scales, it’s low effort to run on a VPS. Shipped a side-project with a couple of PHP scripts a couple of years ago. It works to this day.
Re: Serving a half billion requests per day with Rust and CGI
#10How meaningful is “per day” as a performance metric?
Not at all, it may be a useful marketing metric, but not a performance one. The average load does not matter when your backend can't handle the peaks.
True, though a lot higher spec'ed systems couldn't handle the minimum 5000 requests/second this implies.