I don't disagree. I'll raise it with some folks internally

Oh and noticed one comment typo

Unfortunately we ran out of time today to finish off the piece to onboard discord users. Early next week seems like the updated ETA.

Which also aligns with a significant performance improvement we're hoping to roll out next week.

looking forward to it 😄

ooh that sounds interesting 👀

Out of interest will the public beta bindings flag be default by then, too?

yeah, get most of your performance ducks in a row before i get ahold of it 😄

If the compatibility date of your worker is 4/18 or newer (which you can start to do Monday) and you don't specify anything, you get the correct R2 bindings.

Awesome, thank you!

You'll probably get access before we unblock the performance. I'm targeting late next week or early the week after because our mantra is reliability >>> performance. Currently the performance bottleneck is ~100-150 reads per second per bucket. If you have a meaningful write workload that performance can drop to ~30 ops per second per bucket. This is due to performance bottlenecks in the metadata layer. Next week's runtime update will have important fixes for the prototyped metadata revamp we've been working on. Transitioning correctly will be what I'm focused on and we'll have a short maintenance window where R2 will go down briefly to transition (no data is lost, maintenance should take < 30 minutes). That should remove the performance bottleneck by making each key independent of every other. I've observed a 10x improvement on the read throughput but I haven't categorized max aggregate throughput for the bucket. I think there's another 30-40x of possible improvement for reads after that. It's hard to say for sure (+ how it maps to aggregate throughput, unclear). My performance goals for R2: * Very attractive IOPS this year, bottleneck by our storage nodes. We probably won't beat other cloud providers but we should be competitive. 2023 will be about focusing our attention on lifting the bottlenecks in the storage nodes. * Very competitive latency performance. * 0-config performance. You don't need to ramp your request rate up or down. You don't need to architecture your object names in any special way.

> 0-config performance. You don't need to ramp your request rate up or down. You don't need to architecture your object names in any special way. 👏👏👏👏

Ok no problemo

Looking forward to it :)

have operation prices been mentioned anywhere yet? even just the beta pricing, i'd be curious

operations as in read/write?

if so, here

yep

oh wow that's very good

ok actually i think i was off by a zero. i believe it's pretty in-line with like GCS (google)

haven't checked aws

aws and gcp both have 5/m write and 0.4/m read

so it's cheaper than both

(plus free egress)

Cloudflare is the cheapest and theoretically the best since it replicates data and doesn't tax bandwith :))))))))

When a request to R2 returns "304 Not Modified", does it also count as a read operation?

For GET requests yes. That is consistent with other providers. The part I’m less unsure about is conditional put which no one else implements. Should that bill as a PUT or a GET. Still discussing that with the product team.

what’s that, put with an etag/hash included 304s if it’s the same and creates or replaces the object otherwise?

User > Standard Cache > Argo Tiered Cache > R2 Colo Cache > R2 Origin In the worst cold case scenario that revalidation hits the R2 origin and it will be counted, what if the object is already cached in the Standard Cache or one of the upper Argo Tiered Cache? (Assume ~1 KB JSON objects and eventually consistency is enough)

Yes. I don’t know if it’s actually possible over HTTP (I think it is?) but we also have Workers which lets us bypass some of that