-
Notifications
You must be signed in to change notification settings - Fork 371
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
Reproduce slowness of relayer when spawned before channels are bootstrapped #1977
Conversation
Here are the logs after applying the fix in #1991:
To no avail, the relayer still takes about 40 seconds to start. |
…slow-ternary-transfer-test
Shall we keep this as a regression test now that #2007 is merged? |
We can perhaps put an upper bound on how long the "slow" test can run and fail the test if it goes over that? |
I'm not sure if the GitHub CI is suitable for detecting this kind of slow down. We could put a rough timeout on the workflow, but that is applied to running all tests together. Otherwise we could run it as a separate step with timeout after the main test, if that helps. |
This has been fixed by #2007. |
Closes #1978.
This PR is based on #1976.
Description
This PR reproduces the relayer runnning very slowly in the test
test_ternary_ibc_transfer
when the relayer is spawned first before the channels are being bootstrapped. The test can be reproduced manually by running:cargo test -p ibc-integration-test --features manual -- test_slow_ternary_ibc_transfer
The ternary IBC transfer test performs IBC transfer between 3 fully connected chains. i.e. there are IBC channels established from chains A to A, A to B, A to C, B to B, B to C, C to C. As compared to the binary transfer tests, due to the increased number of chains and channels, the relaying seems to slow down exponentially as a result.
In the original test, the relaying starts pretty much immediately after an IBC transfer is initiated. But in this modified test, relaying the first IBC transfer takes 41 seconds, and subsequently 71 seconds, 75 seconds, and 118 (!) seconds for each transfer to be relayed. This is a rather significant delay that should not be ignored.
There don't seem to be any significant slow down if the relayer supervisor is spawned first in the case of binary transfer test, which can be reproduced manually with:
cargo test -p ibc-integration-test --features manual -- test_slow_ibc_transfer
More investigation is needed to determine why the relaying slows down exponentially as more channels are added after the relayer starts, but not if the channels are added before the relayer is started.
PR author checklist:
unclog
.docs/
).Reviewer checklist:
Files changed
in the GitHub PR explorer.