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

[GOT-66] Create stress tests to understand how read-query load affects syncing time #315

Open
jsign opened this issue Sep 30, 2022 · 0 comments
Labels
linear Sync issue with linear research

Comments

@jsign
Copy link
Contributor

jsign commented Sep 30, 2022

We should try to understand better how read-query load affects background work regarding syncing chains.

Technically speaking, we use WAL mode in SQLite, so readers shouldn't block writers, compared to the default journal mode where this isn't the case. Using WAL mode was done intentionally exactly for this reason.

This can help us understand better the limits of the validator in particular VM setups (e.g: the one we use in the cloud).

In any case, reads are easy to scale since they can be executed in "replica" nodes without interfering with writes. That's a more complex setup since it requires SQLite replication (we can use excellent projects out there) and other processes running, but is totally doable. But, it might be good to understand that limit better and know if we're getting closer to working on it.

GOT-66

@jsign jsign added the research label Sep 30, 2022
@jsign jsign moved this to 🆕 New in go-tableland backlog Sep 30, 2022
@brunocalza brunocalza added the linear Sync issue with linear label Mar 23, 2023
@brunocalza brunocalza changed the title Create stress tests to understand how read-query load affects syncing time [GOT-66] Create stress tests to understand how read-query load affects syncing time Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
linear Sync issue with linear research
Projects
No open projects
Status: 🆕 New
Development

No branches or pull requests

2 participants