KV should not have higher latency than R2 generally. R2 can have better latency if you happen to be

KV should not have higher latency than R2 generally. R2 can have better latency if you happen to be in the same region you placed the bucket (which is generally the default if the machine you created the bucket is the same machine making these requests). Even still, for an asset you fetch repeatedly KV should still be faster.

beelzabubOP•3/15/23, 4:10 PM

If you're changing the UUID of the script frequently, that would trigger a cold read every time. So this is very dependent on your test experiment environment.

Bbeelzabub KV should not have higher latency than R2 generally. R2 can have better latency ...

Oleg Isonen•3/15/23, 4:20 PM

We are not changing the UUID of the script during the tests, so its really static. https://webstudio.is

beelzabubOP•3/15/23, 4:35 PM

Ok. Let me take a look

beelzabubOP•3/15/23, 4:38 PM

So just so I'm clear, for example https://webstudio.is/build/entry.client-QHBMJZIF.js is taking 137ms in your screenshot and that's served from KV?

Bbeelzabub So just so I'm clear, for example https://webstudio.is/build/entry.client-QHBMJZ...

Oleg Isonen•3/15/23, 4:49 PM

yes!

beelzabubOP•3/15/23, 5:02 PM

So looking at our backend, it looks like there's no KV asset for that file. It looks like you might be trying to put cache in front of KV but then forgetting to update KV on a miss?

Ivan Starkov•3/15/23, 5:13 PM

Its worker for platform, it has following code.

      // @todo the whole logic looks strange, add test, write what it solves
      if (asset) {
        finalRequest = new Request(
          url.origin + "/" + asset,
          request as RequestInit
        );
      }

      const response = await getAssetFromKV(
        {
          request: finalRequest,
          waitUntil(promise) {
            return ctx.waitUntil(promise);
          },
        },
        {
          ASSET_NAMESPACE: env.__STATIC_CONTENT,
          ASSET_MANIFEST: assetManifest,
          cacheControl: {
            browserTTL: ttl,
            edgeTTL: ttl,
          },
        }
      );

      return response;

      // @todo the whole logic looks strange, add test, write what it solves
      if (asset) {
        finalRequest = new Request(
          url.origin + "/" + asset,
          request as RequestInit
        );
      }

      const response = await getAssetFromKV(
        {
          request: finalRequest,
          waitUntil(promise) {
            return ctx.waitUntil(promise);
          },
        },
        {
          ASSET_NAMESPACE: env.__STATIC_CONTENT,
          ASSET_MANIFEST: assetManifest,
          cacheControl: {
            browserTTL: ttl,
            edgeTTL: ttl,
          },
        }
      );

      return response;

KV is created by using

[site]
bucket = "./public"

[site]
bucket = "./public"

section in toml file
and exists and filled

4453161ad26e32a617c6c6d4b837c9d9/workers/kv/namespaces/989796259c334124b2e868bd9a0c3849

4453161ad26e32a617c6c6d4b837c9d9/workers/kv/namespaces/989796259c334124b2e868bd9a0c3849

Ivan Starkov•3/15/23, 5:15 PM

This library https://github.com/cloudflare/kv-asset-handler std code is used for static assets hosting

Ivan Starkov•3/15/23, 5:17 PM

timings are very unstable and sometimes can be very good

Ivan Starkov•3/15/23, 5:17 PM

But next reload

Ivan Starkov•3/15/23, 5:17 PM

Ivan Starkov•3/15/23, 5:17 PM

Font timing (r2 with cache rule) is independent

beelzabubOP•3/15/23, 5:18 PM

That library seems to have a lot of magic and I've never looked at it before

Oleg Isonen•3/15/23, 5:20 PM

The weird thing is that R2 has consistently good timing. Should we put everything in R2 then?

beelzabubOP•3/15/23, 5:20 PM

No. I'd recommend using KV properly

Ivan Starkov•3/15/23, 5:21 PM

Can it be because of worker is blocked by some heavy script, like first request is coming and cause some heavy job on worker - really 100-200ms computation, and consequent requests are waiting for worker finish that task?

beelzabubOP•3/15/23, 5:21 PM

The problem is that that kv-asset-handler is doing a lot of complicated things more than just hitting KV

beelzabubOP•3/15/23, 5:21 PM

It's using cache in front of KV and trying to honor caching headers from the origin afaict.

beelzabubOP•3/15/23, 5:22 PM

Any one of those things could be tripping you up in theory

beelzabubOP•3/15/23, 5:22 PM

Try disabling

shouldEdgeCache

shouldEdgeCache

in your options and see if that fixes it

Ivan Starkov•3/15/23, 5:23 PM

Trying

beelzabubOP•3/15/23, 5:23 PM

I think you do that by eliding ASSET_MANIFEST

beelzabubOP•3/15/23, 5:24 PM

(i.e. setting it to undefined)

Ivan Starkov•3/15/23, 5:27 PM

Seems like this https://github.com/cloudflare/kv-asset-handler/blob/c198236dc7444f99acad1f8ccffa2532b8fda879/src/index.ts#L227 i.e. bypassCache also set shouldEdgeCache=false

beelzabubOP•3/15/23, 5:28 PM

Yeah maybe

beelzabubOP•3/15/23, 5:30 PM

@cherryjimbo might know more about the specifics of this library as he seems to be the primary maintainer.

Ivan Starkov•3/15/23, 5:38 PM

Tried with cache bypass, seems like become worse but hard to say. Like 30/60ms worse

beelzabubOP•3/15/23, 5:39 PM

Can you try without that library at all?

Ivan Starkov•3/15/23, 5:41 PM

For me it looks like highlu correlated with 2nd request we have

Ivan Starkov•3/15/23, 5:41 PM

If it came from cache everything else is fast, KV etc

beelzabubOP•3/15/23, 5:41 PM

That library is doing too many fancy things. If KV is your source of truth, you can just read from it and set whatever cache control headers you need (e.g. you can store it within the KV metadata if you need to customize).

Ivan Starkov•3/15/23, 5:41 PM

If it calculated (and its really heavy on calulation) everything from KV is slow

James•3/15/23, 5:43 PM

Sorry I’m on mobile so can’t help too much at the moment, but kv-asset-handler shouldn’t be that far off normal KV performance. It uses

cache

cache

manually though

Ivan Starkov•3/15/23, 5:56 PM

I disabled heavy script and have same results for all requests

Ivan Starkov•3/15/23, 5:56 PM

beelzabubOP•3/15/23, 5:57 PM

What do you mean by "heavy script"?

Ivan Starkov•3/15/23, 5:57 PM

So it looks like we have single worker which does not process KV until heavy work on requested script

Ivan Starkov•3/15/23, 5:57 PM

Heavy - heavy in computation like 200ms to compute response

Ivan Starkov•3/15/23, 5:58 PM

?css-hash

?css-hash

in screenshots above

beelzabubOP•3/15/23, 5:59 PM

?css-hash in the last screenshot shows 41ms

beelzabubOP•3/15/23, 5:59 PM

So not disabled?

Ivan Starkov•3/15/23, 5:59 PM

I disabled generation inside and everything become works well

Ivan Starkov•3/15/23, 5:59 PM

Something left but small like return new Response ("")

beelzabubOP•3/15/23, 5:59 PM

Is that asset being generated dynamically instead of from KV?

Ivan Starkov•3/15/23, 6:00 PM

Yep that single asset was geerated dynamically

Ivan Starkov•3/15/23, 6:00 PM

all others are not

beelzabubOP•3/15/23, 6:00 PM

I don't think that fully explains it though as requests to independent assets should be unique parallelized requests.

Ivan Starkov•3/15/23, 6:01 PM

But that looks like requests to a single worker. Probably because we are using saas workers

beelzabubOP•3/15/23, 6:01 PM

I don't think I follow.

// @todo the whole logic looks strange, add test, write what it solves if (asset) { finalRequest = new Request( url.origin + "/" + asset, request as RequestInit ); } const response = await getAssetFromKV( { request: finalRequest, waitUntil(promise) { return ctx.waitUntil(promise); }, }, { ASSET_NAMESPACE: env.__STATIC_CONTENT, ASSET_MANIFEST: assetManifest, cacheControl: { browserTTL: ttl, edgeTTL: ttl, }, } ); return response;

KV should not have higher latency than R2 generally. R2 can have better latency if you happen to be

Similar Threads

Similar Threads

Similar Threads