Low cache hit rate

[mbarbero]

On open-vsx.org deployment, we currently see 30-40 hits/sec with 0% cache hit rate (due to no-cache headers returned at the application level).

Caching of static resources should be agressive. Also, all anonymously fetched content (e.g., https://open-vsx.org/api/vscode/less) should be set cacheable — even a 10min cache can help mitigate a DoS attack.

[spoenemann]

Static resources can be cached with application properties: https://github.com/EclipseFdn/open-vsx.org/pull/287/files#diff-e67aaef8c148d95abdc5932168870f3b0a8c089420cd97e73a325aa1817d96d8

I added a 10 minutes cache to the main API endpoints. However, I'm not sure whether we should do the same with the search endpoint. WDYT?

[mbarbero]

Thanks for the update. The 4h for static + 10min for main API endpoints is a great start.

I'd suggest to keep the search endpoints with no cache for now. We can always decide later to add a short one from production data.

[mbarbero]

We still see some static resources not being cache, e.g.

wget -S https://open-vsx.org/api/svelte/svelte-vscode-nightly/99.1.39/file/logo-nightly.png

Would you mind re-opening the ticket?

[agafgfafa]

Navigate to https://open-vsx.org/, click something, press back ... the home page must reload everything from the server. That is so inefficient.

[svenefftinge]

fixed with #259

[mbarbero]

Is it possible to have a new docker image (https://github.com/orgs/eclipse/packages/container/package/openvsx-server) that I can deploy to production for immediate benefit? Thanks.

[spoenemann]

The IntegrationTest failed: https://github.com/eclipse/openvsx/runs/2092850785

There seems to be a problem with testcontainers. That should be fixed, or we disable the integration test to get the caching update out more quickly.

[mbarbero]

Any update on the integration tests and the availability of a new docker image so we can deploy with more caching?