That’s not what you’re doing, you’re redirecting them to the new page
That’s not what you’re doing, you’re redirecting them to the new page
Vyes and serving response of trigger route
KOn the new page, the Worker isn’t being hit.
Vwhat do i need to change?
KDoes anybody uses TCP Stream in cloudflare workers, when I try to run
read() without server response it got stuck? #TCP Sockets read() function got stuckKIs it considered a bug or can it be prevented if it happens?
RIs there a way to tell cloudflare where I want the worker to work? (certain region instead of close to my region)
RMore 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 tailI'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