If your origin is anycast like CDN -> CDN it would pick a single location to put everything through
If your origin is anycast like CDN -> CDN it would pick a single location to put everything through which wouldn't work well latency wise lol
Cif all your origins are simple unicast/not more then one location per ip should be fine though, it'll just pick a location nearby to check and more cache hits.
You can see all of the locations it picks for each Origin IP when its on
You can see all of the locations it picks for each Origin IP when its on
DDoes this have a bit of delay? Did a few requests that have
cf-cache-status: HIT from a Worker and it's still zeros
CThere is def some delay. Keep in mind there are some exceptions too, for example R2 Custom Domains won't use Tiered Caching
Cand nor will cache api
DI'm using B2 
Doddly B2 seems to have better perf in many of my use-cases compared to R2. Go figure.
Cnot frequently requested stuff or something? I thought B2 had pretty high latency overall, espec p99
Dmy
fetch
KI eventually ditched B2 due to having to retry about 1% of all uploads (they failed or gave me cryptic Backblaze-only errors). The speed was fine when it worked tho
Dso I've heard that before, but somehow I don't seem to have ever ran into it with aws4fetch.
Dwas your ~1% error rate with a Worker?
KNo, I used the Backblaze API and the S3 interface and a regular Cloudflare CDN endpoint
DHow were you using Cloudflare with B2 without a Worker?
KIt was only on uploads, and it was frustratingly definitely some kind of Backblaze problem (like the error message would say I ran out of "tomes" and stuff like that, which are their low-level storage system objects)
Doouf.
KYou can just CNAME a Backblaze public bucket with Cloudflare
KYep, that's what we did. Our upload code would retry like 4 times if it got a Backblaze error before actually giving up. It's p. unacceptable.
DHow big are your files on average? I'm wondering why I haven't ran into it yet.
KLike 500kb-1mb images, not very frequent
KYou might also see:
KWhich are all this tome system choking
C"retry 9 more times"
Ccould be that your client automatically retries, some of the s3 libraries do I think on 5xx errors
DI usually have retries set to 0 in aws4fetch
Cliving life on the edge
CB2 has a article here: https://www.backblaze.com/blog/b2-503-500-server-error/
I guess they use 500/503 errors to switch between vaults and such, no LB in front, it gets routed to a vault and if it fails because it's full the request dies. Kind of interesting
I guess they use 500/503 errors to switch between vaults and such, no LB in front, it gets routed to a vault and if it fails because it's full the request dies. Kind of interesting
As we’ve described in our developer docs, the best decision is to write your integration in a way that it retries in the event of a 500 or 503.
CI guess that's not for S3 though although it can still run into similiar errors
UBackblaze is the king of being slow and constant errors
Cuploads are free because half the time they fail /s
U
realCreally cheap though
CI've wanted to try B2 before but I don't have large enough needs and we get R2 free
UI used B2 for a little bit for storing on demand video clips from live streams and it was super bad switched to stackpath which was just resale of wasabi or whatever
UBut very good and fast
JWe're big B2 users and I'm a fan of their service. You do have to design with 5xxs by design though when using their native APIs at least: https://www.backblaze.com/docs/cloud-storage-integration-checklist
Tools that integrate with Backblaze B2 Cloud Storage and are featured on the Backblaze B2 integrations page must follow specific guidelines.
JIf you use their S3 compatible API, it's all transparently handled for end-users nowadays, which is very nice
Jor at least, in theory it should, lol
Dahhh, that makes sense, I've always be using their S3 API. Never wanted to touch a native cloud storage API 
Junfortunately we were about ~18 months early with our integration so the S3 compat API didn't exist 
DSemi-related question, is there any perf difference between virtual and path-style S3 APIs?
Din practice it looks like both point to the same IP anyway
JI think the path-style is old and planned to be deprecated
Jbut otherwise I don't think so
JCIf you're talking R2 S3-compat specifically I really doubt there would be any diff, already a compat layer on top
Dis it actually gonna be deprecated though?
Cthey entirely stopped that though as noted at the top, and said they would provide at least a years heads up before doing it again, so it looks like it'll still be around for a while
Jyeah fair, maybe one day
HHey all, does anyone have experience in setting up DDNS for bypass rule in Access policy (zero trust)?
I used to have static IP from my ISP and I just bypassed access via that IP but I don't anymore. Wondering if anyone has experience in using DDNS for the bypass rule?
I used to have static IP from my ISP and I just bypassed access via that IP but I don't anymore. Wondering if anyone has experience in using DDNS for the bypass rule?
