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

sending transactions from pods #32

Open
bernardoaraujor opened this issue Oct 28, 2022 · 1 comment
Open

sending transactions from pods #32

bernardoaraujor opened this issue Oct 28, 2022 · 1 comment

Comments

@bernardoaraujor
Copy link
Contributor

@pepoviola has mentioned that zombienet allows us to send the transactions from the same pod where the target node is running.

we should use this issue to discuss and brainstorm a few things:

  • we'll need a script to be executed on the pod... how does this script look like, and how do we get zombienet to trigger it?
  • by doing this, we are essentially eliminating the variable of network latency between transaction sender and target node... is that a desirable thing? IMO yes, but I need to reflect more
@bredamatt
Copy link
Contributor

bredamatt commented May 15, 2023

This would also relate to Versi based deployments, and indeed it is an interesting question.

IMO it is a good idea for measuring a maximum (s)TPS number which is core to the measurement, but is not very realistic. In practice, RPC clients may be located in different locations than nodes. In other words, transactions may be signed in a more distributed manner where there is some latency between validator / collator nodes and submitters of transactions.

This realistic scenario can be introduced by using the chaos mesh we have in Versi, whilst still maintaining the desired deployment strategy (i.e. on the same VM / kubernetes node as the validator/collator nodes). This way we can report metrics which are both theoretically maxima, and more realistic.

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