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

Implement database connection pooling for Cardano transaction repository #1760

Closed
8 tasks done
jpraynaud opened this issue Jun 17, 2024 · 0 comments · Fixed by #1761
Closed
8 tasks done

Implement database connection pooling for Cardano transaction repository #1760

jpraynaud opened this issue Jun 17, 2024 · 0 comments · Fixed by #1761
Assignees
Labels
performances 🥇 Performances

Comments

@jpraynaud
Copy link
Member

jpraynaud commented Jun 17, 2024

Why

We have noticed during performances optimization of the Cardano transaction prover that the connections to the SQLite database is a bottleneck. A first prototype showed throughtput increased by a factor of ~x10 when implementing resource pooling on the connections to the database. However, in order to be properly implemented, the resource pooling must be done in a setup where all write queries are implemented with SQL transactions.

What

Implement a connection pooling mechanism for the Cardano transaction repository and remove the performance bottleneck on the Cardano transaction prover.

How

  • Implement a pooling mechanism for the Cardano transaction repository
  • Add a configuration parameter for the connection pool size
  • Use the connection pool size parameter in the devnet
  • Use the connection pool size parameter in the terraform infrastructure
  • Use the connection pool size parameter in the CI
  • Set the GitHub Actions environment variables
  • Update documentation
  • Benchmark the performances improvements
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performances 🥇 Performances
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant