That is exactly the reason I wrote the post! Those advice are based on specific use case, bug or outdated kernel. The jemalloc (Digital Ocean post) case is a good example, it just doesn't (didn't) know about THP https://github.com/jemalloc/jemalloc/issues/243
I can only repeat it: "Measure, measure and measure again!"
> My github portfolio is a means for me to determine if a potential employer is suitable for me, not the other way around. It's not a test for me to pass, it's a test for a potential employer to pass.
> But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly.
Khm... What if you have millions of requests per second with tight latency requirements measured in milliseconds; and a bunch of business logic to fit into that. Such optimizations aren't so silly.
There are different scenarios on both client and server sides.
I agree with you, usually you shouldn't optimize to the point when code quality starts suffer. It's all about trade offs. If you have one or two hundred servers and millions of RPS then it could be reasonable. Or coming back to the code quality, perhaps it's worth to re-visit the efficiency part and find another algorithm/ approach (someone suggested FSM in comments in this case)
I doubt that exactly that will work. There are tens of thousands of different UAs (maybe 100K). Perhaps some kind of tiny (few CPU cache lines) cache for most popular UAs could help. But again: measure, measure, measure :)
Yes, you're right. There are many ways to block robots: IP, UA, behaviour analysis. An advertising company has to have UA based filtering to be compliant with standards. However, the focus of the blog post is on performance rather on how to block bots.