4 ms·
You learn by doing it, but it's also not incredibly complex for nearly all SaaS products (most simply are not at the scale that actually necessitate it). At it
by SkyPuncher 3y ago
You learn by doing it, but it's also not incredibly complex for nearly all SaaS products (most simply are not at the scale that actually necessitate it).
At it's most basic, you need insight into bottle necks. That means some sort of profiling tool. From there, you start looking at slow things and making decision.
In my experience, those decisions largely come down to a few things:
* Did I miss a basic optimization, like an index on a query, some sort of caching, an N+1, etc, etc. Don't look too deep, here.
* Am I hitting hard limits of my hardware. Memory, CPU, disk throughput, network throughput, etc, etc. If you are, you should ask can I simply add more/bigger servers? If you are small, the answer is almost always "yes".
* Am I doing something really ineffectively? This is similar to point 1, but looks at things a bit more holistically. This might be slow external network requests, a lack of caching, an inefficient join or query. Spend a lot of time here before moving onto the next point. These fixes are almost always easier than architectural changes.
* Do I need to make an architectural change? Look for things poor dependency isolation, spaghetti code (really spaghetti data), and components that can be generalized.
- tstrimple 3y ago> That means some sort of profiling tool I’ve really enjoyed using Application Performance Monitoring tools which sample in real time across production workloads to get insights into application bottlenecks. Sometimes the APM tool alone is good enough to track down performance issues and sometimes you’ll need to drop down to language specific profiling tools. But it’s a great way to get pointed in the right direction based on actual app usage.
- mattbrewsbytes 3y agoI also recommend an APM tool. An answer people will probably dislike and this may sound careless, but for the large majority of SaaS web applications out there scaling horizontally in the middle/web tier behind load balancers and having a beefy DB server with replication to a stand-by is going to be the answer like 99% of the time. From a business perspective. when you are operating in the cloud, the cost of having engineers spend a lot of time trying to tune something to run optimally can be more costly than just adding more cloud servers or increasing the size of existing or both. This is time lost that those engineers could be building new features of a product in order to bring in more revenue. Time-box that analysis to like 1 developer day (e.g. equivalent to 8 devs in a 1 hr meeting) and move on with business work. Or just increase resources til the problem goes away, assuming you've solved obvious things like N+1's, etc.