Initial commit for producer/consumer loadtest client

[philipsu522]

Describe your changes and provide context

Loadtest improvements:

• Move to a producer consumer model
• Use random numbers for seqno (need to merge this pr to Add config to disable seqno sei-cosmos#385)
• Allow for long running tests
• Remove writing data to a "result" file that then needs to be queried with another tool, instead generate stats on the fly

Testing performed to validate your change

• Ran on loadtest cluster

[philipsu522]

will revert go.mod changes once i merge sei-protocol/sei-cosmos#385

[udpatil]

is this necessary after disabling seqno check? couldn't we just set them all to a constant seqno?

[yzang2019]

I think you probably have to at least make these transactions different because mempool will reject duplicate txs. However, even random seq can still have a chance to result in duplicates, we should probably just switch to a monitonically increasing seqno here?

[yzang2019]

I wonder whether we need to apply rate limit for signing tx or not at all. We should apply the rate limiting only for the broadcast tx right? For signing txs, we can keep signing and generating tx as long as the queue/channel is not full

[udpatil]

we likely want this to be async, right? otherwise there would be a bottleneck for sending txs since theyll need to sequentially pass checkTx to enter mempool?

[yzang2019]

We want to do sync here and wait until the response back, otherwise you have to query the tx and figure out when it is completed. We can put each tx into a separate goroutine though

[udpatil]

Note, we may want to change this default to like 1, since otherwise it will send a TON of messages, whereas before the config fields were named weirdly such that txs per block = 500 and msgs per tx = 10 would result in 50 txs with 10 messages each IIRC. now, it would ACTUALLY result in 500TPS of 10 messages PER tx

[yzang2019]

Did we change the concept here? I think previously if target is 500, batch size is 10, then it will only send 50txs and each tx will contain 10 messages

[philipsu522]

logic has not changed. will set this to 1 as default

[yzang2019]

Instead of using ticker to do rate limiting, I think a better approach is just to use "golang.org/x/time/rate": https://github.com/sei-protocol/dex-indexer/blob/main/cmd/index_producer/main.go#L63

[yzang2019]

We want to do sync here and wait until the response back, otherwise you have to query the tx and figure out when it is completed. We can put each tx into a separate goroutine though

[yzang2019]

Did we change the concept here? I think previously if target is 500, batch size is 10, then it will only send 50txs and each tx will contain 10 messages

[philipsu522]

b/c sender uses broadcast mode = block, we can use client-side metrics to calculate tps