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

Improve Someguy routing api performance #88

Open
2color opened this issue Nov 14, 2024 · 0 comments
Open

Improve Someguy routing api performance #88

2color opened this issue Nov 14, 2024 · 0 comments

Comments

@2color
Copy link
Member

2color commented Nov 14, 2024

Context

It's becoming increasingly clear based on real world testing that someguy could benefit from various optimisations, e.g. internal caching to improve performance.

Experience running Someguy as a public good has given us insight into some known problems, trade-offs, and potential improvements.

The primary use case for someguy is short-lived and resource constrained IPFS client, e.g. browsers.

This issue aims to capture what we know, the difference aspects of performance in addition to linking to the relevant sub-issues.

Metrics

In order to improve any aspect, we need to have better observability so we can confirm theories about why requests are slow.

nd-json vs. json

Someguy supports both json (default) and nd-json content types. For almost all use-cases, nd-json performs better because results, e.g. providers, are streamed to the user as they are discovered through DHT traversal. This is also the default in the helia delegated routing client

The only disadvantage of nd-json, is that results cannot be cached by Cloudflare CDN.

JSON and internal timeouts

The main problem observed with the default JSON responses, is that someguy has neither timeouts for incoming http request nor DHT/IPNI routing requests, which leads clients to hang until a timeout in one of the intermediate layers (nginx or Cloudflare for the public endpoint).

It's probably sensible to add an upper bound on routing requests:

  • Less hanging in-flight requests (an attack vector)
  • It will result in faster JSON responses
  • There are anyway diminishing returns on waiting longer when finding providers, you may find more, but at the cost of the client giving up on trying.

HTTP Caching

Since someguy exposes an HTTP API, HTTP caching provides a robust and composable mechanism to improve query performance. Someguy sets the cache-control headers as defined in the spec, which are respected by nginx and Cloudflare.

Active peer probing and internal caching

The peer store in go-libp2p caches peer records for 15 minutes.

Provider routing requests often return peers without any multiaddrs. This forces clients to make a separate peer routing request.

#53 explores the idea of adding active peer probing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant