Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulation functionality #43

Open
Shmuma opened this issue Aug 7, 2021 · 2 comments
Open

Simulation functionality #43

Shmuma opened this issue Aug 7, 2021 · 2 comments

Comments

@Shmuma
Copy link

Shmuma commented Aug 7, 2021

It would be awesome to add ability to simulate the system, not just draw the diagram.
It not neecesary need to be precise, just automate the “back of the envelope” calculations system architects normally do.

Ideally, with properties specified, it should make possible to identify bottlenecks in the system. Would be priceless utility in all kinds of “what-if” checks (if our DB performance drops 2 times, what will be the impact on the client requests?)

@honzaap
Copy link
Owner

honzaap commented Aug 7, 2021

Yes! This was actually my initial thought of the app, that it would look for and display these kinds of things, I just never knew how to do it (in the sense of what to show and what not to...) I'll try to make something like this, if you have any more ideas on how or what to make, let me know.

@Shmuma
Copy link
Author

Shmuma commented Aug 7, 2021

In principle, as a first step the following extensions could be implemented:

  • for producer nodes, approximate output rate should be definable as parameter
  • for consumer nodes, consumption rate should be specified
  • button "simulate" which triggers the flow analisys (https://en.wikipedia.org/wiki/Flow_network)

After the simulation, actual flow for every node will become available and should be displayed. It could be done in a vairous ways, like ratio between actual and theoretical flow or actual message rate.

In addition, some kind of report could be generated, showing the slowest components.

Of course, this approach will be very rough, not taking into account many aspects of real systems:

  • non-linear congestion of components
  • fluctuations in load (you can have day/night oscillations, sudden spikes, etc)
  • dependency of processing time on data size or other kind of complexity
  • delays in message propagations

But even with simplest form, it still will be useful as first approximation of architecture analisys. And, of course, more complexities could be added later.

In addition, it might be cool to add "stress test" simulation, when producers' rate is increased monotonically to check which components are saturating first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants