I don’t pay for Lichess, love the UX, and I know it’s a labor of love, but come on. Surely Lichess refactoring aren’t so urgent and user critical that they should just go straight to prod?
Yeah, there should be some kind of shakedown test.
But Nah, not every issue can be tested for within the manpower/$ budget. Issues of load being one of them.
A valid strategy is: send it!, work with the beast a bit, if too unruly roll it back. In this case, they tamed the new beast. Not like Lichess is going to lose billions...
Think about it - clients or requests are really just ephemeral ports...
There are something like 30 thousand of them available by default with Linux
If you use sockets you can have as many connections as your system allows for open file descriptors. The upward limit is...
$ sysctl fs.file-max
fs.file-max = 9223372036854775807
apachebench is a decent example of the idea; imagine some proprietary sauce with it
It gets cheaper (and in some ways, more effective) if you actually remove the network -- latency goes down
You can also rate limit it in software, but it's really not analogous in some ways (eg: net.core.somaxconn limitations/realities)
Development time is totally understandable though. It's important I leave my green field of comfort
I'm not saying it doesn't take effort, I'm just saying it can and is regularly done
Regression testing with speed. If you test your features as they're added, niche-ness doesn't matter - you know about it and test it
A regression test quickly turns into a load test if you do them all at once
To be clear, I'm not trying to twist the knife. I understand why it wouldn't be done. I just won't pretend it can't
I've been trying to avoid this 'hindsight is 20/20' thing...
I'm not trying to lay blame - just offer thoughts towards improvement, and encouragement against some defeatist thinking patterns
A lot can be done with very little equipment/time investment
It's not particularly expensive or difficult, but it does need investment