Add generate command and support for data-dependent endpoints#5
Add generate command and support for data-dependent endpoints#5
Conversation
…use between ramp vs. steady bug
…misc style/consistency improvements
…d stats to written logs
|
|
||
| func getLedgerEntryChangesFromMeta(meta xdr.TransactionMeta) ([]xdr.LedgerEntryChange, bool) { | ||
| var changes []xdr.LedgerEntryChange | ||
| switch meta.V { |
There was a problem hiding this comment.
I think you might also be missing the top-level Operations field, yeah? It contains LedgerEntryChanges.
There was a problem hiding this comment.
Also this feels like it belongs in the SDK, just for the future
There was a problem hiding this comment.
I think I addressed this recently, but given that this is new to me, it's worth a second look/huddle if you'd rather. To my knowledge this field is only set when V==0, which I had missed.
|
|
||
| // SeedWriter accumulates seed data into an OutputSchema struct, | ||
| // then encodes it as a single ordered JSON object on Flush(). | ||
| type SeedWriter struct { |
There was a problem hiding this comment.
This would be more idiomatic if it implemented the JSON encoder interface (MarshalJSON) rather than used composition, I think. Also you'd probably want this to implement io.WriteCloser, too.
There was a problem hiding this comment.
Then you'd be able to eliminate the OutputSchema construct
There was a problem hiding this comment.
Eliminating any notion of OutputSchema is tough because it's used on both the read and write side of this (here in writer.go and also in loading in the parameters in run/parameters/load.go), but there's no reason it can't be embedded in SeedWriter instead of being a field, nor is there a reason why this can't implement those interfaces. I also renamed it to SeedData and moved it outside of the writer folder since it's not truly a writer-only object
internal/run/engine/run.go
Outdated
| if err != nil { | ||
| return errors.Wrap(err, "error marshalling JSON request") | ||
| var targeter vegeta.Targeter | ||
| if params, ok := paramCache[ep.DataPath]; ok && parameters.EndpointNeedsData(endpointKey) { |
There was a problem hiding this comment.
Couldn't you remove this conditional and pass null/{} to the non-parameterized endpoints? Seems like it shouldn't matter to the calling context whether or not you need detailed params
There was a problem hiding this comment.
I think I disagree unless there's something I'm missing. In the "if" case, we make bodies (with type [][]byte), which has unique request bodies (that vary in parameters) in it, and in the "else", we're sending the same byte-for-byte request with the one body (of type []byte) in it. The rotating targeter vs. the non-rotating targeter take different arguments and are fundamentally different functions (as we don't have to deal with atomic increments/modulo in the one-body case), so I have them produce entirely different targeters that suit their needs respectively.
2 participants
What
Implements
stellar-rpc-blaster generate, which collects seed data for data-dependent RPC endpoints. The data currently collected includes:ledger_range: the first and last ledger in the range of sampled ledgerstxhash: list of hashes in specified ledger window and if they were successfulcontract_id: list of contract IDs in the windowevent_topics: list of unique contract event topics in the windowledger_keys: list of ledger keys in the window for ledger entries that are of one of the following types:Implements support for data-dependent endpoints in Blaster. The requests of these endpoints vary probabilistically based on constants defined in
internal/util/constants.go. Namely, support was added for:getLedgers, varies on: json/XDR, startLedger, pagination limit + cursor based/startLedger basedgetLedgerEntries, varies on: json/XDR, 1 key/2-10 keys/50-200 keys, keys randomly chosengetTransaction, varies on: json/XDR, hash found/not found -> successful/failed if foundgetTransactions, varies on: json/XDR, startLedger, pagination limit + cursor based/startLedger basedgetEvents, varies on: start/endLedger window, pagination limit, filters (include random contract ID/don't (if included, single ID/2-5 IDs), include 1 random topic filter/don't, include 1 random event type/don't)Why
Blaster currently only supports parameter-free endpoints and it's useful to be able to load test parameter-dependent endpoints with representative sample data.
See #3 and #11 , which are parts of epic #2
Known limitations
N/A