Wes
Wes
PostsComments
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
Also, you mentioned operational needs vs specific POPs... My issue is being too far from my database, there are at least 40 or 50 POPs that are closer latency wise. Is there a plan that would keep me close(r)? I develop stuff for contract and average latency is usually part of the spec. If there is a plan, I can always offer to the customers and if they are fine with the cost that would work as well. On a completely different front. Having D1 available in a location is Latin America also solves my data locality problem.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
No description
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
Sure thing. I'll run them later today as soon as I get some time.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
I'm on Workers paid but CDN free... When I try to go into the ticketing area I get sent here: https://developers.cloudflare.com/support/account-management-billing/cannot-locate-dashboard-account/ My workers connect to a PostgreSQL database, run a few queries and return a json, really simple stuff. I tried to use D1, only to find it does not run in SA and that means a guaranteed 150-200ms best case scenario, that was a bit of a let down, hence the move to PG.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
The going far is the part that troubles me... moving from 2-10 ms RTT to 100-150ms RTT to my database means 3 quick queries go form 15-20ms to 400-400ms. Response time increases build up real fast.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
No description
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
At the end of the day, I don't really mind being proxied/routed away from my local POP, but I would love to be proxied to one of the dozens of POPs that are in the same country at least. Crossing a continent is what adds latency and it's what's creating problems for me so I think I only have two questions: 1) Why go to a different continent instead of a closer POP? (capacity?) 2) Is there anything that can be done about it?
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
IP wise I am being routed consistently to a local IPv6 according to ICMP. The CF resolved IP address changes but it is consistently under 20ms for response time on ICMP. What is not being consistently routed is the worker request, internally it appears. I seem to enter the CF network at a local POP, usually either GRU or GIG, ICMP shows that, on both ping and traceroute, and SSL negotiation times do as well. Once I gent into the CF network, my workers run either in IAD or EWR, so this is CF routing the HTTP request internally, not at the peering layer but once they already have control of the request. From what I remember from the time I worked in telco, a route is a route. Even when it's flapping, requests at(virtually) the same time, will hit the same path, and BGP is not all that fast(talking seconds, no ms here). at the IP level I am hitting local 100% of the time according to ICMP (when pinging the same IP curl is resolving) so it's hard to imagine a situation where my ICMP request would hit local but the HTTP request hit remote for the same destination IP at the same time, even with anycast. That sort of network problem would mean trouble for the most basic stuff like handshaking on TCP or SSL. That is why I'm assuming I hit local and after I hit local, then the request get's routed/proxied internally, by CF, at the http layer, to a remote location. I don't know why CF would do that, but I imagine limited capacity at the POP would be one. As for workers running on the same edge machine they hit, that is the theory, yes. But on partial rerouting scenarios, load shedding and limited CPU/Memory capacity I have to imagine it gets more complicated than that and they would rather proxy the request than fail it altogether. That being the case, then I would also assume there are provisions in the infra to trigger that rerouting for other reasons. I'm guessing here on everything besides the network stuff so take it with a grain of salt.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
Well, I'd appreciate any tips as to how to route stuff locally. Running in any in-coutry DC would probably work latency wise, but when the worker is running in the us but pulling data from a DB in Brazil it just doesn't work latency wise due to the DB RTT time. before anyone suggests, D1 is also not an option as it does not run in south america at all.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
on a separate note, it seems not even the plan tier can guarantee placement since in this last run PRO is local but BIZ is remote. 
{
  "cdn-cgi": {
    "local-free-v4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-ent-IPv4-spectrum": [
      "IPv4",
      "colo=GRU"
    ],
    "local-1111-ipv4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-free": [
      "IPv6",
      "colo=GRU"
    ],
    "local-pro": [
      "IPv6",
      "colo=GRU"
    ],
    "local-biz": [
      "IPv6",
      "colo=IAD"
    ],
    "local-ent": [
      "IPv6",
      "colo=GRU"
    ],
    "local-1111-ipv6": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent-IPv6-spectrum": [
      "IPv6",
      "colo=GRU"
    ]
  },
  "durable-object": {
    "colo": "EWR",
    "cached": true
  }
}
{
  "cdn-cgi": {
    "local-free-v4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-ent-IPv4-spectrum": [
      "IPv4",
      "colo=GRU"
    ],
    "local-1111-ipv4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-free": [
      "IPv6",
      "colo=GRU"
    ],
    "local-pro": [
      "IPv6",
      "colo=GRU"
    ],
    "local-biz": [
      "IPv6",
      "colo=IAD"
    ],
    "local-ent": [
      "IPv6",
      "colo=GRU"
    ],
    "local-1111-ipv6": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent-IPv6-spectrum": [
      "IPv6",
      "colo=GRU"
    ]
  },
  "durable-object": {
    "colo": "EWR",
    "cached": true
  }
}
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
just re-ran the test. I'm resolving to Remote Address: [2606:4700:3030::6815:3513]:443, my latency to that address is under 20ms, but the cf-ray comes marked as IAD. based on that, I would assume it is not a routing issue as I'm entering CF at a POP that is near, perhaps not the nearest, but good enough. From there I'm then internally routed to IAD.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
But I'm getting to the edge on GRU, so it does not seem routing related. I'm 13 ms form the IP that is responding to my request. It is just the worker allocation that seems to be traversing the CF network and running up north.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
also, Vivo has 3 ASN (resulting from acquisitions) that I'm aware of so that might be it as well. I remember getting IPs from at least two of them in my home fiber at different times.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
anything I could do? I can definitely do Pro if it will fix it, but Business is out of my price range unfortunatelly.
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
Not sure it's ISP related though as it was working yesterday... perhaps prefix related? Os cost related as suggested by @Hard@Work ?
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
ISP is Vivo
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
{
  "cdn-cgi": {
    "local-free-v4": [
      "IPv4",
      "colo=YYZ"
    ],
    "local-1111-ipv4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-ent-IPv4-spectrum": [
      "IPv4",
      "colo=GRU"
    ],
    "local-free": [
      "IPv6",
      "colo=IAD"
    ],
    "local-pro": [
      "IPv6",
      "colo=EWR"
    ],
    "local-biz": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent": [
      "IPv6",
      "colo=GRU"
    ],
    "local-1111-ipv6": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent-IPv6-spectrum": [
      "IPv6",
      "colo=GRU"
    ]
  },
  "durable-object": {
    "colo": "EWR",
    "cached": false
  }
}
{
  "cdn-cgi": {
    "local-free-v4": [
      "IPv4",
      "colo=YYZ"
    ],
    "local-1111-ipv4": [
      "IPv4",
      "colo=GRU"
    ],
    "local-ent-IPv4-spectrum": [
      "IPv4",
      "colo=GRU"
    ],
    "local-free": [
      "IPv6",
      "colo=IAD"
    ],
    "local-pro": [
      "IPv6",
      "colo=EWR"
    ],
    "local-biz": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent": [
      "IPv6",
      "colo=GRU"
    ],
    "local-1111-ipv6": [
      "IPv6",
      "colo=GRU"
    ],
    "local-ent-IPv6-spectrum": [
      "IPv6",
      "colo=GRU"
    ]
  },
  "durable-object": {
    "colo": "EWR",
    "cached": false
  }
}
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
if setting up a zone in PRO solves the issue, I'll gladly do it 😄
36 replies
CDCloudflare Developers
Created by Wes on 11/20/2024 in #workers-help
Workers running in a different continent from the requester
I have workers Standard(Paid), accessing from worker-name.account.workers.dev so technically no zones involved I think 😅
36 replies