You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could it be useful to lower the healthcheck interval?
From: HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
To: HEALTHCHECK --interval=5s --timeout=3s --start-period=5s --retries=20 \
Rationale: If you have a service that has IPFS/Kubo as dependency, about 15/20s of boot time get added for every fresh deployment.
This is not an impactful case for production cases, but pre-production & CI cases might see some improvement. In my personal case, I've already seen that gain when using a modified version of Kubo with these settings.
I might be missing something, but I cannot see many drawbacks to have a high interval value, although this could be due to missing some deep internal elements of a DAG resolution at boot time.
PS: if required & desired, I could do the PR myself, although I guess first it's better to agree here about going forward with this change.
Best.
The text was updated successfully, but these errors were encountered:
Checklist
Description
Could it be useful to lower the healthcheck interval?
From:
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
To:
HEALTHCHECK --interval=5s --timeout=3s --start-period=5s --retries=20 \
Rationale: If you have a service that has IPFS/Kubo as dependency, about 15/20s of boot time get added for every fresh deployment.
This is not an impactful case for production cases, but pre-production & CI cases might see some improvement. In my personal case, I've already seen that gain when using a modified version of Kubo with these settings.
I might be missing something, but I cannot see many drawbacks to have a high interval value, although this could be due to missing some deep internal elements of a DAG resolution at boot time.
PS: if required & desired, I could do the PR myself, although I guess first it's better to agree here about going forward with this change.
Best.
The text was updated successfully, but these errors were encountered: