51–60 of 124 posts
Well done Cockroach labs team. This data is very valuable and much appreciated. A small nitpick if you're reading. Fig 19: Sotrage: Azure Write Throughput the y axis has an incorrect label of "1,00" when it should be "1,000"
Earlier quoted context omitted.
No, I contacted them directly after seeing this report and confirmed they did not even use accelerated networking (which is a free, but opt-in service on Azure), much less things like placement proximity groups (which only recently went public). So machines were communicating across availability zones (separated physically by miles and logically by additional networking layers) and a bunch of networking was happening…
Why is accelerated networking opt in? It seems like making it default would improve these comparisons a lot and would help a lot of your customers who likely haven't found this setting either.
> ...in 2018, AWS outperformed GCP by 40%, which we attributed to AWS’s Nitro System present in c5 and m5 series... In 2020, we see a return to similar overall performance in each cloud. How did GCP and Azure catch-up to AWS Nitro in one year which IIRC is a coming together of minimalistic micro-vms, hardware-accelerated network and IO cards, hardware offload for encryption and other maintenance tasks... a work that…
Meltdown and Spectre did a real number on the c5 and m5 instance types. Amazon's original fix reduced performance substantially, which lot's of people noticed, but no one knew why till the vulnerabilities were announced. Meanwhile Google built a clever workaround which minimized the pain. It was really a mic-drop moment from Google and I wish someone would dig in deep and tell the whole story. At this point I'm sure…
> ...in 2018, AWS outperformed GCP by 40%, which we attributed to AWS’s Nitro System present in c5 and m5 series... In 2020, we see a return to similar overall performance in each cloud. How did GCP and Azure catch-up to AWS Nitro in one year which IIRC is a coming together of minimalistic micro-vms, hardware-accelerated network and IO cards, hardware offload for encryption and other maintenance tasks... a work that…
I think all the clouds use the same basic physical CPU sets, so I'm more surprised about the perf being much different in previous years, than I am about the perf being similar this year. Maybe the hypervisor layer was much more efficient at AWS or something?
Direct PDF link: https://cdn2.hubspot.net/hubfs/1753393/guides/Cloud_Report_2...
These reports behind an email wall frustrate me to no end. I don't want to receive your spam to read a single article!
Earlier quoted context omitted.
These reports behind an email wall frustrate me to no end. I don't want to receive your spam to read a single article!
Its rather expensive (and time consuming) to produce reports like this. They are doing it to generate leads.
That’s basically the entire point of GDPR. Stop making people trade personal information for “free” content.
Earlier quoted context omitted.
Yeah, and without comparing spot/interruptible prices, these results are meaningless for me.
You wouldn't typically run your database VMs on spot/interruptible instances.
How many people are running a cloud account with ONLY a cockroachdb in it?
Your point seems pretty obtuse tbh.
Earlier quoted context omitted.
You wouldn't typically run your database VMs on spot/interruptible instances.
You wouldn’t typically run your databases in a cloud environment on your own VMs - you would use a managed service.
Looking at the Azure networking numbers I wonder if they got their configs correctly optimized. Azure networking was always tricky to get best performance when I used it heavily at my last co.
No, I contacted them directly after seeing this report and confirmed they did not even use accelerated networking (which is a free, but opt-in service on Azure), much less things like placement proximity groups (which only recently went public). So machines were communicating across availability zones (separated physically by miles and logically by additional networking layers) and a bunch of networking was happening…
Can you answer why -- for the love of God -- why Azure IPv6 networking is doled out in microscopically small /124 blocks (16 addresses)!?
The standard is a /64 at a minimum for residential connections, and /48 is recommended for most premises, particularly business connections. Azure could easily obtain a /32 for each of their regions, providing a very roomy 4 billion /64 scopes per data centre.
Right now, if I want to "embrace IPv6" and all of its advantages, such as a flat address space and the elimination of NATs, I will have to either:
1) Juggle a bunch of /124 prefixes and carefully allocate services to them. This is a load of fiddly scripting or manual work.
2) Probably be forced to NAT anyway!
3) Pay for addresses that ought to be too cheap to meter.
Earlier quoted context omitted.
These reports behind an email wall frustrate me to no end. I don't want to receive your spam to read a single article!
My understanding is that gated content is not compliant with GDPR which requires consent to be given freely and unconditionally. Can anyone comment?