based on that header count it looks like they're both workers, but you're saying one uses cache and
based on that header count it looks like they're both workers, but you're saying one uses cache and the other one doesn't, or am I misunderstanding?
C(I would make sure to send a handful of requests as well to make sure the connection and everything is warm before looking at the response, REST clients don't make the best benchmarking tools)
DIm really just curious how I can get my latency down lower, a endpoint with nearly 0 extra computation ontop of hono takes 3x as long to execute
Dah, did not think about that. let me push without a cache and check the numbers
DSemi related, hows the experience with KV / D1 for a db and ratelimiting? Currently using turso and upstash and the latency is pretty high
CKV <- uncached two central stores, cached is still ~20-30ms slower then normal cf cache/workers
D1 -> single location for now, only in Durable Object supported locations as well
For Rate limiting, there is a binding you can use in Workers now to use that colo's/dc's normal ratelimiting
D1 -> single location for now, only in Durable Object supported locations as well
For Rate limiting, there is a binding you can use in Workers now to use that colo's/dc's normal ratelimiting
Cah I'm just a bit confused on exactly what you are comparing. If it helps, here's a simple worker with Enterprise routing that returns the url requested: https://quick-test.workers.tylerobrien.dev/, no cache or anything
D30-50ms, seems to be the same as my endpoint without cache headers added
Care you close enough to ORD that 7ms is physically possible or it could just be local cache of whatever utility you are using/something else?
could try pinging their hostname and seeing icmp latency
could try pinging their hostname and seeing icmp latency
WHello, How are you? everyone!
I created the worker, do you know how to integrate with my project?
I created the worker, do you know how to integrate with my project?
DI am pretty close to a datacenter, not sure if its 7ms close
Cwhat's the endpoint of unkey that you are testing? Curious if I can see the diff at all
DI was testing last night, let me find the url real quick
Coh it may be helpful to explain as well: No matter what cache headers you return from a worker you'll never be able to use edge cache unless you specifically use cache api in the worker (which is of course an invocation even just to get a cached response)
CWorkers are a layer in front of cache
DI used the
hono/cache package inside of my middleware, they covered everything elseDI just specified a cache name and maxage
Cahh ok sounds handy, probably cache api under the hood then
CThe Cf-Cache-Status header is an easy way to tell the cache status of an object. If it's missing, didn't even try cache
DThis was what I was using, 150 first hit, then 30-40 after that
DI set a limited use on the key too, I dont mind if people have it
DI do not see this inside of the headers for unkey, im assuming Hoppscotch wouldn't hide it somewhere
DI do not have this header
D"The Cache middleware uses the Web Standard's Cache API. It caches a given response according to the Cache-Control headers." Could this be something with the browser instead of CF?
Cwith the cache api the usual implementation is such that it would be missing if the cache missed, try hitting it a few times?
Cit's also possible unkey doesn't use cf cache or uses it indirectly, like with kv
DYea stil no header, let me see with postman
Cfwiw for me (to ORD) that endpoint is slower or comparable to a direct worker
Cex:
Dah, may just be hoppscotch. I am getting more realistic numbers with postman
C
Cdirect worker
DI would assume it wouldn't do something like that due to 60k stars on gh
Dbut postman is consistent around the 45ms mark
CI mean if you type
ping api.unkey.dev what's the latency you see icmp?Cwell a more popular worker might be slightly faster because it's already in memory, but it should be within a few ms. Additionally higher plans get more locations/better routing, but you're hitting the same
D18ms avg, practically the exact same as me
DPossibly they just have some amazing db routing. They advertised 22ms response times somewhere too
Chttps://github.com/unkeyed/unkey/blob/main/apps/api/wrangler.toml looksl ike durable objects are involved, ord is a dc supporting DOs
GitHub
Open source API management platform. Contribute to unkeyed/unkey development by creating an account on GitHub.
DOkay, ill go look into this a good bit and see what I can do. Thank you for the help
Ccan see they use cache as well https://github.com/unkeyed/unkey/blob/ae36a6aa5e4d0d55cacc812d14ebc044f6e3ec91/apps/api/src/pkg/keys/service.ts#L171
Cand it looks like their DB is just planetscale w/ drizzle
https://github.com/unkeyed/unkey/blob/ae36a6aa5e4d0d55cacc812d14ebc044f6e3ec91/apps/api/src/pkg/db.ts
https://github.com/unkeyed/unkey/blob/ae36a6aa5e4d0d55cacc812d14ebc044f6e3ec91/apps/api/src/pkg/db.ts
Cthey have a readonly db as well so I assume they've just got a bunch of planetscale replicas: https://planetscale.com/docs/concepts/regions
Cthat only really matters for the first uncached hit, then it's all Cache API and Durable Objects it seems
Dah didn't know ps had replicas, that will be useful.
DThats the whole reason I used turso haha
DYea this helps a ton, experience on workers is great compared to hosting on a dedi
Cyea shouldn't be too much you couldn't replicate and get close numbers to them, I assume that 7ms was just that tool being drunk or caching somehow, you get ~18ms to the dc
Cincrease cacheTtl to keep things cached locally for longer without hitting the central store if it works for your app
https://developers.cloudflare.com/kv/api/read-key-value-pairs/#cachettl-parameter
https://developers.cloudflare.com/kv/api/read-key-value-pairs/#cachettl-parameter
DI want to use a .dev.vars for secrets but my
wrangler.toml