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

feat: add cache to check endpoint #1391

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vasco-santos
Copy link
Contributor

This PR adds cache response for check endpoint. Specially when content is Pinned and Filecoin Deal is made the response will be exactly the same.

In this PR, response is cached for 10 minutes when content requested has no deals yet and the content is Pinned. When it has deals, we rely on default cache TTL of CF cache API

It will avoid two heavy DB queries, including a query to cargo schema.

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Feb 17, 2022

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: 29504d0
Status: ✅  Deploy successful!
Preview URL: https://464f825a.nft-storage-1at.pages.dev

View logs

@vasco-santos vasco-santos mentioned this pull request Feb 17, 2022
28 tasks
@vasco-santos vasco-santos force-pushed the feat/add-cache-to-check-endpoint branch from 6cd8272 to e361d46 Compare February 17, 2022 11:03
@vasco-santos vasco-santos requested review from hugomrdias and alanshaw and removed request for hugomrdias February 17, 2022 11:09
@vasco-santos vasco-santos force-pushed the feat/add-cache-to-check-endpoint branch from e361d46 to 29504d0 Compare March 1, 2022 15:09
// cache status response with max age
'Cache-Control': `public, max-age=${CACHE_MAX_AGE_NO_DEAL_YET}`,
}
: undefined // cache default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the default though?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should really be specific about the cache period. In this case it's unknown when another deal for the CID may become available so I expect we'd only cache for a relatively short period of time...

Was there an observed perf issue here? This makes the route more complicated and it's used in our monitoring so could mask any underlying issue...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per https://developers.cloudflare.com/workers/runtime-apis/cache/#headers and https://developers.cloudflare.com/cache/how-to/configure-cache-status-code/#edge-ttl default would be 120 minutes.

We can probably use default if we have at least a deal instead?

Was there an observed perf issue here? This makes the route more complicated and it's used in our monitoring so could mask any underlying issue...

Yesterday we had some timeouts for instance, I don't have empirical answers for this at the moment. The main motivation for this is the work in #1386 which will increase significantly the calls to check API

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a CID is pinned and in has deals, then some caching of the repsonse would be sensible. Otherwise, caching should be minimal or avoided here.

I'm against landing #1386 as I dont want us to hit the nft.storage api for every single CID fetched from the gateway.

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

Successfully merging this pull request may close these issues.

3 participants