I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do a quick mental arithmetic and conclude that we have ~70ms to serve each request. (Though peak RPS is usually more relevant when calculating perf numbers; traffic tends to be lumpy so we need overhead to spare at all other times which makes the average much less impressive-sounding.)
Indeed it's just the most performance-critical part of the stack that happens to involve ruby because I needed a shim between redis and powerdns. I write it as a quick hack years ago and have never had to make any changes to it.
I think that shim still uses ruby 2.6, I may try to upgrade it to 3.3 with yjit and see what the latency drop is, which is probably a more interesting number anyways, but again only really matters for a single caching request that only happens once in a while.
The real reason I continue to use ruby is because it's a quick way to get things done on business logic heavy web apps, but I continue to be impressed how much I can get away with using it for things it's really not known for being good at. I run into people often that refuse to use it for absolutely anything because there's a perception that it's "too slow", but when pressed I learn that they're not really working on anything that requires high performance provided by more esoteric languages with stricter memory management that is very likely nerfing their productivity unnecessarily. My goal here was to push back on that perception a bit, not to make the dns shim sound impressive.
The reverse is good also. 0.00005 vs 0.005 cents/request seems very close as a human. But considering that times the seconds in a day or month results in very different values.
I also like to double check these kind of numbers and basically agree with your take. Although, I like to use a 28 day month and an 8-10 hour day rather than assuming smooth traffic over 24 hours. Even with all that, 1/2 a billion is well under 50 req/sec which is not a big deal for the rendering servers. All that traffic coming together on a database server might be a bottleneck though.
Yea 14 qps isn’t high performance. I think the parent comment is right that most people don’t work on high performance software and so Ruby will work fine.
But something to keep in mind. I’ve seen servers before that could serve in the 100,000 QPS range on a single instance! They weren’t written in Ruby.
For reference:
I always do this when I see large-sounding query counts; a month has a lot of seconds in it, and it’s easier to visualize only one at a time: I can imagine hooking a speaker up to the server and getting a 14Hz buzz, or do a quick mental arithmetic and conclude that we have ~70ms to serve each request. (Though peak RPS is usually more relevant when calculating perf numbers; traffic tends to be lumpy so we need overhead to spare at all other times which makes the average much less impressive-sounding.)