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.

Sign up for GitHub

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

Jump to bottom

Define storage use cases and workloads #45

Closed
1 task
lasarojc opened this issue Dec 23, 2022 · 2 comments
Closed
1 task

Define storage use cases and workloads #45

lasarojc opened this issue Dec 23, 2022 · 2 comments
Assignees
@jmalicevic
Labels
duplicate This issue or pull request already exists storage
Milestone
2023-Q1

Comments

@lasarojc
Copy link
Contributor

Was tendermint/tendermint#9943

Problem definition

We do not have a complete picture on how our users as well as different Tendermint components interact with storage. We therefore need to collect all the relevant use cases for the storage backend:

  • Who and how are the using Tendermint storage (validators, sentries, full nodes, etc., but with specific emphasis on what people are doing with full nodes)
  • How are different Tendermint components using the storage.

DoD

  • A list of different users, their typical usage patterns and issues with regards to Tendermint storage.
@lasarojc lasarojc mentioned this issue Dec 23, 2022
Open
21 tasks
@lasarojc lasarojc added the duplicate This issue or pull request already exists label Jan 3, 2023
@lasarojc
Copy link
Contributor Author

lasarojc commented Jan 3, 2023

This is a duplicate of #68

@lasarojc lasarojc closed this as completed Jan 3, 2023
@jmalicevic
Copy link
Contributor

jmalicevic commented Jan 5, 2023 •
edited

Sorry @lasarojc , I saw it was not in the tracking issue and thought it was not here. Thanks for porting it the first time!

@thanethomson thanethomson added this to the 2023-Q1 milestone Feb 25, 2023
cometcrafter pushed a commit to graphprotocol/cometbft that referenced this issue May 13, 2024
@mergify @czarcas7ic
perf(event bus): Remove expensive Logger debug call in PublishEventTx…
d1b1de2 
… (backport cometbft#2911) (cometbft#2937) (cometbft#38) (cometbft#45)

Component of cometbft#2869

This on its own is an expected 1% speedup to blocksync on osmosis
mainnet right now.

I originally considered keeping the log lines but with only creating the
logger cost if there is an error, but these are debug logs I've never
seen. I think its better to just remove these debug logs directly,
rather than worry about maintaining them. These aren't even that
concerning scenarios I feel like, as more of the stack moves away from
these.

---

#### PR checklist

- [x] Tests written/updated - Covered by existing tests
- [x] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [X] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [X] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec
<hr>This is an automatic backport of pull request cometbft#2911 done by
[Mergify](https://mergify.com).

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
Co-authored-by: Andy Nogueira <me@andynogueira.dev>
(cherry picked from commit a9991fd)

Co-authored-by: Adam Tucker <adam@osmosis.team>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jmalicevic jmalicevic

Labels
duplicate This issue or pull request already exists storage
Projects
None yet
Milestone
2023-Q1
Development

No branches or pull requests
3 participants
@thanethomson @lasarojc @jmalicevic