4 ms·
I spent about a decade doing performance work, Ie: app crashes, can't handle the load, can't scale up to what we need, etc. I think there are at least parts to
by poulsbohemian 3y ago
I spent about a decade doing performance work, Ie: app crashes, can't handle the load, can't scale up to what we need, etc. I think there are at least parts to answering your question:
1) Get good at testing and profiling applications so that you can identify specific bottlenecks and then find architectural solutions to those pain points.
2) Get good at looking at an architectural model and identifying those pain points even before you've built a system. BUT - sometimes the problem is that you have incomplete information about the demands on a system and/or in other cases someone will want to over-architect from the beginning - which in some cases even becomes the bottleneck.
I guess I'd add perhaps a third option based on your specific question: Learn what it means to scale software. Sometimes that means low level things in software. Sometimes that means architecture. And sometimes it's just throwing a shit-ton of hardware at a problem. So in your desire to scale software, you need to know what technical solutions are available to you and make the tradeoffs depending on the resources (time, money, people, etc) available.
So how do you learn this stuff? Well, short of companies paying you like they did in my case, maybe consider some problem you want to explore, build a prototype, and consider introducing different types of both load and errors into the system so you can see how the system performs. A few years back I was asked to build a system to ingest what the client thought might be 10,000 images a day and run through a series of steps with those images. Well, the client effed up and I discovered that the real demand was more like 10,000,000 images a day that needed to be processed. So I had to modify the architecture. Point being - you could come up with some scenario like that, build yourself a little prototype lab experiment, and start playing with what happens as you modify parts of the architecture.
- sagelemur 3y agoAny good tools to build these prototype experiments?
- poulsbohemian 3y agoWhatever code you are handy with. You'll need land generator tools and profiling tools - and picking those out and developing skills with them is a step toward understanding scale too. In the course of building those prototypes, you are learning something about scale too... what if I spawn a bunch of threads to handle this task at this point? What if instead I put each of those tasks on a queue and have a task handler? What if I take this engine piece and put in on separate hardware? What if I have a bunch of these engines running in parallel? What if I make this change to the DB connection? What if I remove the dependency on the DB entirely? It's easy to say a lot of this stuff is basic computer science you should have learned in school, but that's not reality. There's a lot of emphasis put on algorithmic complexity and efficiency, there's a lot less put on systems design and architecture. You kinda have to do it in the wild to learn it.