nate berkopec

@nateberkopec
1.4K Followers
32 Following
3.2K Posts
Author, The Complete Guide to Rails Performance. Co-maintainer of Puma. https://speedshop.co
websitehttps://www.speedshop.co
bloghttps://www.nateberkopec.com
pronounshe/him
some postsmirrored from other sites
@zenspider I got a podcast outreach one which may have in retrospect been a phish but it was pretty weak tbh. I feel left out 😆
@nateberkopec I’ve gotten 3 custom crafted email since the axios event whose approach fit what was described by axios and google. Chilling

Puma 8.0 "Into The Arena" has been released!

1. Framework/lib authors can move threads into a special "high IO" pool
2. single/cluster DSL hooks for easier config
3. API for adjusting threadpool size at runtime (who would want to that? stay tuned...)

Re: Axios - so I guess if you're an OSS maintainer, your threat model is now: "I may be targeted by a state-sponsored hacking group at any time."
Has anyone applied an autoresearch loop (successfully or not) to a Ruby project outside of Shopify yet? I would like to cover it in my RubyKaigi talk.
@Schneems @getajobmike @Ryanbigg in theory that's what semver is for. I think the difficulty comes in that "major" bumps may be related to one cross-dependency but not another (I broke Rails, but I didn't break hanami)

@getajobmike @Ryanbigg yeah I'd rather people not set "< X" arbitrarily, even before X is released

If this is in reaction to an incompatibility discovered in minitest v6 seems totally reasonable to me

The #1 most important performance work in almost any web app is converting full navigations into SPA/route changes/Turbo Drive clicks. You are converting a ~4 second experience into a 400ms experience every single time. Nothing else comes close.
Super common mistake I see in Ruby setups: don't allocate more than 1 CPU core to background job containers. You're only running one process in there (usually) so there's no reason to allocate > 1 core.
After ~9 months of experimentation (synthetic and in prod), I can say definitively that MALLOC_CONF has no measurable effect on any Ruby workload that I've seen. Don't bother.