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

Improve Soroban I/O controls in loadgen #4231

Open
dmkozh opened this issue Mar 7, 2024 · 1 comment
Open

Improve Soroban I/O controls in loadgen #4231

dmkozh opened this issue Mar 7, 2024 · 1 comment
Assignees

Comments

@dmkozh
Copy link
Contributor

dmkozh commented Mar 7, 2024

Currently Soroban loadgen allows us to configure the number of entries to write and the total amount of kilobytes to write. However, when computing the inputs to the loadgen contract, we round up the size of every entry written to 1 KB. So e.g. if we request to write 10 entries with the write bytes limit of 3KB, then the contract will try writing 10 KB worth of data and fail due to exceeding the transaction write limit. We should increase granularity of the contract inputs, for example:

  • Make contract accept the size of each entry written in bytes
  • Compute the per-entry size on the loadgen side:
    • Make sure to account for the 'baseline' entry size (~50B) when computing the size to pass to the contract. It's fine for entry to have 0-byte payload
    • Increase the transaction write bytes if necessary to be at least baseline_entry_size * num_entries_written.
    • Estimate the instructions using the final write bytes values (rounding up to 1 KB)

It also would be nice to control the read entries separately from the write entries. It should be sufficient to simply allow us to configure the number of read bytes/read entries separately and add the extra entries to the footprint (on top of the RW entries).

@bboston7
Copy link
Contributor

Hey @dmkozh, I've got a couple clarifying questions:

  1. Where does the existing loadgen contract perform reads? I see writes to persistent storage here, but no corresponding reads. Is there an implicit read somewhere?
  2. Can you expand a bit on the per-entry "baseline" data? What is this data? Metadata about the entry? How can I tell how big it is?

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

No branches or pull requests

3 participants
@bboston7 @dmkozh and others