Skip to content
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

/routing/v1 http client metrics and configuration #115

Open
2 tasks
lidel opened this issue Apr 8, 2024 · 0 comments
Open
2 tasks

/routing/v1 http client metrics and configuration #115

lidel opened this issue Apr 8, 2024 · 0 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@lidel
Copy link
Member

lidel commented Apr 8, 2024

Problem

Seems that we have hardcoded some settings related to delegated routing over HTTP

15s timeout on cold cache might lead to undesired denial of service if content is only announced to IPNI at cid.contact, and either client or server are under load so receiving response takes more than 15s

Solution

I think we should expose http routing client metrics to see if/when things fail, and make things configurable (at least the routing timeout), and use our infra to adjust the default based on real world performance:

  • expose timeout as a configuration setting, allowing us to fine-tune it on ipfs.io infra
    • config option for adjusting timeout should follow whatever naming convention we end up in feat!: independent dht and routing v1 flags #113
    • ipfs.io gateway infra timeouts (HTTP 504) ~1m, so I think it would not hurt if we wait for routing response bit longer than 15s
  • have success/failure metrics for each defined /routing/v1 endpoint
@lidel lidel added the need/triage Needs initial labeling and prioritization label Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

1 participant