yea that sounds right. Sorry, not familiar with the workers side of cf
yea that sounds right. Sorry, not familiar with the workers side of cf
CI was just asking because the opposite is expected, and CF has publicly stated before Workers are cheaper for them (as in, less latency, as cache is spread out through the DC, but Workers can run right there) then Cache hits are. For me a simple worker returning html is ~50-55ms, and cache is somewhere between ~50-60ms
Dinteresting, not too sure why that’s happening then
Cdo you have smart placement enabled or anything?
Dpossibly i’m close to a Cache data center? it’s a dramatic difference
Di do but last i checked it said i didn’t have enough data
Call DCs can execute Workers, same as all can do Cache
Ccheck the cf-placement response header
Dcf-placement: local-ORD
D
DIm currently comparing my latency to a service like unkey where their latency is dramatically lower, both of us use cf workers
CDoes the Cf-Ray response header for both return the same location?
DJust ran on a different endpoint (195ms-> 5ms) and it has the exact same cf-ray
Cbased 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