When 'from' account has not enough balance, the transfer fails (it does not fail the whole test). 'from'/'to' accounts are choosen randomly. When all transfer fail, the test fails (see here).
The test is time bounded: 60 seconds. We have no concurrency in the test and amount of transfers is around 38. There is (9/10)^38 ≈ 1.8% probability that we'll never attempt to transfer from 0th account, so all transfers will fail.
The result of the test is reported this way in given case:
(Not quite obvious on the first glance, but look at :ok-count 0.)
There are some ways to resolve it or decrease probability of the fail:
Distribute the initial total amount across all accounts.
Enable concurrency.
Always make the first transfer from 0th account.
Allow negative balances.
A fix for #96 may also decrease probability of the fail due to insreased overall amount of transfer attempts per second.
Uniform initial distribution or permitting negative balances are only true solutions, they also resolve the problem with a lot of failed transfers. See below.
I looked over several other tests implementations:
CockroachDB distributed balance uniformly (see here and here).
Ignite distributes them too (see here, here and here).
YugabyteDB sets the first account to an initial value and others to zero (see here and here).
So, it seems, there is no canonical way to choose initial balances. OTOH, if we'll distribute them uniformly, we'll make more successful transfers, so the test will be more powerful.
Full log: logs.txt.
More detailed info: jepsen-single-instance.zip (see tarantool-3f568c339221ac10948c0dd29e405c0f224597dc/20211029T163440.000Z/).
I would also highlight that even when the test in its current implementation does not fails, it generates much less successful transactions, if we'll compare it with the uniform balances distribution case or negative balances case. So our test lacks some stress testing power just because of the bad initial balances distribution.
The test creates 10 bank accounts and set initial balances:
The 0th account has balance 100, others have 0.
Next, the test starts to perform transfers from account to account:
When 'from' account has not enough balance, the transfer fails (it does not fail the whole test). 'from'/'to' accounts are choosen randomly. When all transfer fail, the test fails (see here).
The test is time bounded: 60 seconds. We have no concurrency in the test and amount of transfers is around 38. There is
(9/10)^38 ≈ 1.8%probability that we'll never attempt to transfer from 0th account, so all transfers will fail.The result of the test is reported this way in given case:
(Not quite obvious on the first glance, but look at
:ok-count 0.)There are some ways to resolve it or decrease probability of the fail:
Uniform initial distribution or permitting negative balances are only true solutions, they also resolve the problem with a lot of failed transfers. See below.
I looked over several other tests implementations:
So, it seems, there is no canonical way to choose initial balances. OTOH, if we'll distribute them uniformly, we'll make more successful transfers, so the test will be more powerful.
Full log: logs.txt. More detailed info: jepsen-single-instance.zip (see
tarantool-3f568c339221ac10948c0dd29e405c0f224597dc/20211029T163440.000Z/).I would also highlight that even when the test in its current implementation does not fails, it generates much less successful transactions, if we'll compare it with the uniform balances distribution case or negative balances case. So our test lacks some stress testing power just because of the bad initial balances distribution.