It locks laws database for reading on database updates for a while.
That means new HTTP requests in highload environment stuck on database updates. It increases response time in such scenarios. Clients can lose requests by timeout and the overall SLA of the service will be far from %99.9999.
Please, consider using RCU container for database object instead of std::sync::Arc<tokio::sync::Mutex<Box<T>>.
It looks like such container is implemented here https://crates.io/crates/rcu-clean and is ready for production!
However, can you provide any benchmarks, that exactly in this holywar-bot using RCU container will improve performance? I cannot accept such changes without proper benchmarks.
I've found the following line: https://github.com/ZaMaZaN4iK/holywar-telegram/blob/cf4fc11bb1587d5abd79611b597d543cf5c1bfde/src/fetch_database.rs#L16
It locks laws database for reading on database updates for a while. That means new HTTP requests in highload environment stuck on database updates. It increases response time in such scenarios. Clients can lose requests by timeout and the overall SLA of the service will be far from %99.9999.
Please, consider using RCU container for database object instead of
std::sync::Arc<tokio::sync::Mutex<Box<T>>
. It looks like such container is implemented here https://crates.io/crates/rcu-clean and is ready for production!