darosior
commented
2 years ago Master, -n 20: 45 passed, 5 skipped in 335.05s (0:05:35)
Master, -n 10: 45 passed, 5 skipped in 412.12s (0:06:52)
This branch, -n 10: 45 passed, 5 skipped in 290.53s (0:04:50)
This branch, -n 20: 45 passed, 5 skipped in 251.27s (0:04:11)
393 further increases the load on the coordinators and the Postgre backend. I have considered a number of things (a thread pool in the coordinator, polling vaults in parrallel in the sigfetcher, a cache for
get_sigsresult in the functional tests, ...). I think in the end we just have to face the fact that our protocol is (purposefully) inefficient and signature fetching is slow. Still, this is a small improvement on the state of things that helps to prevent timeouts in #393.Using a single Postgre backend and a regular coordinator per instance worked for a time, but it's getting to its limits. The functional tests, when ran in parrallel, put an unreasonable load on the Postgre backend. This leads to spurious failures and timeouts that are hard to deal with in the
coordinatordorrevaultdbinaries themselves without optimizing for functional tests.. Which isn't a realistic load.I tried to implement a cache to get_sigs requests using a proxy between the revaultds and the Coordinator in a single instance. Although it (partially) solved the timeouts in the RPC commands that hit the coordinator, it slowed tests down by a lot.
Instead, here we implement a fully in-RAM coordinator for the lowest possible response time. After all, we don't need to persist the data for the functional tests and we can afford a few more MB of RAM usage. Of course, we keep the possibility of running using the real coordinator, but we would probably not do so in the CI that is already too slow. 3 tests would be skipped, though. But not the most important ones, and we don't only rely on CI anyways. As a by-product, we can now run the functional tests without having to start a Postgre backend beforehand. I think it can help new contributors a lot.