Rule 1 for performance optimization: measure before trying to make any changes. It’s easy to waste a lot of time and energy optimizing something that isn’t actually going to meaningfully improve your web app’s performance.
Personally, I like Sentry. They have a pretty generous free tier and a great code/db tracing tool.
(And yes I see that the author lists ‘measure’ as their second point. I think they’re mistaken.)
You have to design it to perform; optimization speeds up hotspots in the design. But no optimization will make your app scalable or perform well under load. You can throw money at it by scaling vertically or horizontally, but that won't fix bad design (though it'll keep things going).
> , performance should be a consideration from the start
Don't obsess over this. Obsess over documenting your design decisions - why you decided one algorithm or pattern over another and why. Then _if_ after load testing you need to optimise you'll understand some of the tradeoffs you'll have to make (all decisions are tradeoffs).
5 comments
[ 4.0 ms ] story [ 24.9 ms ] threadPersonally, I like Sentry. They have a pretty generous free tier and a great code/db tracing tool.
(And yes I see that the author lists ‘measure’ as their second point. I think they’re mistaken.)
You have to design it to perform; optimization speeds up hotspots in the design. But no optimization will make your app scalable or perform well under load. You can throw money at it by scaling vertically or horizontally, but that won't fix bad design (though it'll keep things going).
Don't obsess over this. Obsess over documenting your design decisions - why you decided one algorithm or pattern over another and why. Then _if_ after load testing you need to optimise you'll understand some of the tradeoffs you'll have to make (all decisions are tradeoffs).
Then if you detect inefficiency you can optimize the code and not the architecture.
I am building something with this mindset now, hopefully it will work