More specifically for Workers Routes to leverage API speed from my servers which reside in n.virgini
More specifically for Workers Routes to leverage API speed from my servers which reside in n.virginia
RI feel like if I my worker goes from my location to NVirginia instead of NVirginia worker goes directly to nvirginia and then sends me the results, nvirginia worker would be fatster
HThat sounds like Smart Placement. You aren't able to manually tell it where to spawn the Worker, but it should automatically determine which colo to spawn in to get itself closest to your origin(s)
RBy default, Workers and Pages Functions are invoked in a data center closest to where the request was received. If you are running back-end logic in a Worker, it may be more performant to run that Worker closer to your back-end infrastructure rather than the end user. Smart Placement automatically places your workloads in an optimal location that minimizes latency and speeds up your applications.RSo the worker is indeed doing some back-end logic in the worker, that's the reason I want it to be spawned close to the server
RIs it possible to see logs of my latest worker runs? to know wher eit was spawned?
HYou could
console.logrequest.cf.colo field, then view it in live logs/wrangler tail?RI'm seeing real-time logs and I can see it
Rso, it does it in France (FRA) as it seems
Rand I need it to be around NVirginia, you think I should enable Smart Placements?
KSmart Placement is automatic and runs it based on where the RTT would be lowest based on your subrequests - if you make enough subrequests to a server there, it'll put it closer to there
Rokay checking it now
DI'm assuming each subrequest takes less than 30ms of CPU time 
Doh wait
Dit would be clocked as if it was one request
D...weird.
CWhen a user sends a request, they get routed to a specific machine in a specific colocation/datacenter in a specific PoP. That machine/metal spins up an isolate for your worker, which has its own memory. Connection keepalive will keep them connected to the same metal for a bit, so you might see it "working" and using your in-memory objects repeatedly, but any other client/new connection would be randomly routed to a different machine
https://developers.cloudflare.com/workers/reference/how-workers-works/
https://developers.cloudflare.com/workers/reference/how-workers-works/
The difference between the Workers runtime versus traditional browsers and Node.js.
CNot even cache is per PoP, it's per colo/datacenter. Some PoPs like ORD are made up of mutiple colos each with their own cache (called multi-colo pops, MCPs)
Cbut yea the guarantee is really only per request
Isolates are resilient and continuously available for the duration of a request, but in rare instances isolates may be evicted.Even if they connect to the same metal/machine I believe, they might connect to a different isolate
Because there is no guarantee that any two user requests will be routed to the same or a different instance of your Worker, Cloudflare recommends you do not use or mutate global state.quotes from: https://developers.cloudflare.com/workers/reference/how-workers-works/
CYou can use the Cache API to get per-colo cache
https://developers.cloudflare.com/workers/runtime-apis/cache/
https://developers.cloudflare.com/workers/runtime-apis/cache/
RGuys, what is the expected time to get a response from workers?
I am seeing a weird timing issue.
I have created an API route that return {}. empty object.
When I request it from my location (Europe to NVirginia) I get the response within 180ms.
When a worker requests that data, the worker takes 400 to 490ms to return what took me 180ms. (It uses COLO - FRA)
Anyidea why there's such a big overhead when it comes to it? How can I debug all those times to make sure?
I am seeing a weird timing issue.
I have created an API route that return {}. empty object.
When I request it from my location (Europe to NVirginia) I get the response within 180ms.
When a worker requests that data, the worker takes 400 to 490ms to return what took me 180ms. (It uses COLO - FRA)
Anyidea why there's such a big overhead when it comes to it? How can I debug all those times to make sure?
CIf you mean hardcoding the "index" (an array of objects, you said?) in the worker code, if its quick enough to load, CF will warm up your worker during the tls connect and in a lot of cases elimate cold starts:
https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers
If it's anything that can change/calculated off request/cache sort of thing, you'd want Durable Objects most likely
https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers
If it's anything that can change/calculated off request/cache sort of thing, you'd want Durable Objects most likely
RIs there a difference between free version and paid version?
CIf your API Proxied?
In a worker you could time the request
Might just be a routing thing
In a worker you could time the request
const start = performance.now();Could you share the endpoints? Curious if I can repro
const response = await fetch("https://developers.cloudflare.com/");
const end = performance.now();
const timing = end - start; // duration of the subrequest to developers.cloudflare.com
Might just be a routing thing
RCan I DM you for the endpoint?
CSure
SI noticed that requests are cached with workers by default, how does that work? Is it at the browser level or with cf?
Scan I get some links
CThere's always persistence between requests to the same isolate. The thing is each metal/machine has its own isolates, each colo/cf dc has its own metals, some Pops have mutiple colos, and besides your own connection persistence there's no routing preference to go to a machine that already has your isolate spun up on it
SCloudflare respects the origin web server’s cache headers in the following order unless an Edge Cache TTL cache rule overrides the headers.
HThough note that your Worker cannot do IO in startup mode
HSo you can't fetch stuff or interact with Bindings
SI don't know about other langs, but I found very interesting way around (for rust)..
if we have files predefined, then we can load the content at compile time
example:
this will read the file content and we store it in memory
if we have files predefined, then we can load the content at compile time
example:
this will read the file content and we store it in memory
Scan someone help with this please
HYeah, though too, if you can do that, you should be able to precompute the result too, depending on what you are doing
Dyou can override it by setting cache rules in the cloudflare dashboard ui for any domain
SI am looking for some docs which says how to content is cached
I have a worker deployed, which makes post requests and gets json as response which is cached I think
but I want to know if it's cached in the browser or the local server or is it cached for all workers like kv
I have a worker deployed, which makes post requests and gets json as response which is cached I think
but I want to know if it's cached in the browser or the local server or is it cached for all workers like kv
Dwhich makes post requests and gets json as responsePOST requests aren't going to be cached by default.
S
