alexandrnikitin

I wrote a post on how to measure perf impact and pitfalls of THP some time ago. I hope it helps https://alexandrnikitin.github.io/blog/transparent-hugepages...

> Bad advise...

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.

Nice! Agree with that.

> 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.

It depends. Usually do nothing if that traffic is very low. There's no reliable way to do that. Honeypots and behavior analysis are very useful here.

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 intend to write a separate blog post about low-overhead production monitoring (not sure when it happen though)

Awesome! The talk is great! It would be really interesting to try it. Thanks for sharing.

I'm afraid I can't do that because of proprietary data. I think I can come up with analogous tests using open data. I'll let you know ;)

I have that feeling too. But I found it harder to implement, especially with fallback failure references.

Yes, using honeypots is one of the ways to identify bots. But that wasn't the focus of the post. I'll add some clarification.

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.