search

input-output-hk / jormungandr

privacy voting blockchain node
https://input-output-hk.github.io/jormungandr/
Apache License 2.0
364 stars 132 forks source link

Rework locking and connection pooling in storage #1263

Closed mzabaluev closed 4 years ago

mzabaluev commented 4 years ago

Currently we have an async global lock for the storage backend, guarding a blocking access API. This stands in the way of high-performance implementations of streaming towards network peers that balance asynchronous state of the stream with holding the lock only while the thread is not being blocked, to avoid starving other requests from getting the lock.

One possible solution is to implement a connection pool using bb8 and farm storage queries out to a thread pool running synchronous jobs, giving future/stream handles to the async tasks pending on them. This can keep the chain-libs storage API simple and synchronous, as most backends currently are.

Related: https://github.com/input-output-hk/chain-libs/issues/187#issuecomment-561092079

mzabaluev commented 4 years ago

Cc @eugene-babichenko

eugene-babichenko commented 4 years ago

Thanks for wrapping that up. Basically I'm already working on something like that.

There were problems with sqlite configuration that affected testing, but now I have almost solved them and everything should work fine.

Regarding the implementation on jormungandr side: I think that this is a good idea to use tokio-threadpool particularly because it already deals with this part:

and farm storage queries out to a thread pool running synchronous jobs, giving future/stream handles to the async tasks pending on them

It is already used somewhere in the networking part of the project and we just need to make a global threadpool.

bb8 seems to be a good choice, I like this part.