@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.
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.
50% of what I'm doing at clients these days is addressing unclear expectations of what queue latencies are allowed to be in background work. Almost no one has the proper suite of alerts and observability, queues routinely ballooning without anyone realizing.
It's pretty rare these days to be on a version this old, but if you're still running Ruby 3.1 in production: it's worth upgrading to 3.2+ purely to get YJIT.
LCP is not a good top-level frontend metric to base your entire frontend perf efforts around _unless_ you are specifically targeting search rankings. LCP is not captured on route change/SPA nav or on Safari at all, which means ~50%+ of clicks go unmeasured.
zenspider
