Suggested Solutions

[geradt]

What is missing

This is an amazing tool for users who know how to properly design systems. If its someone learning they don't always know how to solve the bottlenecks. It would be great if there was a way to give the user suggested solutions to the issues the design is facing.

What would it teach

That's the whole point of this feature request. It makes breakscale an even better teaching tool. It teaches users the different ways to solve the problems in the design and tradeoffs for each (if there are more than one way to solve for it).

Anything you already tried

I looked all over the app and clicked on everything and I didn't see this feature in the app already.

[xevrion]

This is a good request and it is not something the app does today, you are right that you looked and it is not hiding somewhere.

Two thirds of it already exists though, just not joined up. Every component has a headroom readout in the inspector, ceiling divided by what is actually arriving, and below 1.0x that node is the thing that cannot keep up. So finding the bottleneck is solved; what is missing is saying what to do about it.

The bit I would want to be careful about is offering several fixes with tradeoffs. One of the challenges in the app exists specifically because the obvious fix, making the database bigger, does not work there, and a suggestion that sounds reasonable and makes things worse is worse than saying nothing. So I would rather start with one suggestion for the worst-off component, tied to what that kind actually does, and only get clever later if it earns it.

[dattatreya-accuknox]

Hey @xevrion awesome project. Just had a small query:-

Can you somehow add a way for us to write code (or maybe pseudo-code) inside servers or dbs to understand how does one's code scales or survives under different condition?

[xevrion]

@dattatreya-accuknox sorry for the slow reply, and thank you.

I do not think this one fits, and it is worth saying why rather than leaving it open.

The engine does not run anything. A component's work is a distribution, not code: a mean service time and a coefficient of variation, sampled per request from a gamma. That is the whole model. There is nothing for pseudo-code to be, because no line of it would ever execute, so the simulator would have to guess what the code costs, and that guess is exactly the number you already type into serviceMs.

The nearest real thing is the thing that is already there. If your handler does a 5ms lookup and a 40ms query, that is a 45ms mean, and if the query is sometimes much slower, that is what cv is for. Both are per-component and both feed straight into the queueing behaviour you are trying to observe.

There is a genuinely useful version of your question that is not this: a component whose service time depends on what the request is, rather than being drawn from one distribution. A cache hit costing 1ms and a miss costing 60ms, say. That is modelling rather than execution and it would fit. If that is closer to what you are after, open it as its own issue and describe the case you had in mind.

Keeping this issue for @geradt's original request, which is a different feature.

[nawazish2]

Hey, I'd like to work on this — happy to start with a single suggestion for the worst-off component (tied to its kind, not a multi-option list) as you outlined. Could you assign this to me?