cockroachlabs / cloud-report Goto Github PK

I've recently read your performance report and noted that according to your recipe, you did not use Proximity Placement Groups in Azure. PPGs greatly reduce latency.

I'm curious if this was an accidental oversight and how results would improve with use of PPGs. Obviously this precludes a multi-zonal or multi-zonal architecture, but high-availability wasn't the aim of your performance tests.

Thanks

Hi,

One of the items in your blog post shows AWS around 8.5 Gbps and GCP around 25 Gbps.

Did you see this ?
https://medium.com/faun/100g-networking-in-aws-a-network-performance-deep-dive-d569c675c6c3

Maybe cockroachdb could be even faster if you tune a bit more ;-)

Kind regards,
Hans
ps. did you see the P4d instances at 400Gbps networking ?

when use
./cloud-report1 analyze -d cloudDetails/cc.json
i get error:
2021/10/04 18:00:55 analyze.go:374: Analyzing report-data/20211004/gce/pd-ssd/logs/n2-standard-4/coremark-results.20211004.11:33:27/success
Error: error parsing "" in report-data/20211004/gce/pd-ssd/logs/n2-standard-4/coremark-results.20211004.11:33:27/single-0.log: strconv.ParseFloat: parsing "": invalid syntax
Usage:
cloud-report analyze [flags]

Flags:
-h, --help help for analyze

Global Flags:
-d, --cloud-details JSON path(s) to JSON file containing cloud specific configuration.
-o, --output-dir string directory to emit results and scripts (default "./report-data")
-r, --report-version string subdirectory for cloud report data (default "20211004")

error parsing "" in report-data/20211004/gce/pd-ssd/logs/n2-standard-4/coremark-results.20211004.11:33:27/single-0.log: strconv.ParseFloat: parsing "": invalid syntax

When delete success file, i get nothing, only clear csv files.
strace for command ./cloud-report1 analyze -d cloudDetails/cc.json

[pid 204326] newfstatat(AT_FDCWD, "report-data/20211004/results/gce", {st_mode=S_IFDIR|0775, st_size=4096, ...}, 0) = 0
[pid 204326] openat(AT_FDCWD, "report-data/20211004/results/gce/cpu.csv", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0644) = 3
[pid 204326] epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3624763416, u64=140118342860824}}) = -1 EPERM (Operation not permitted)
[pid 204326] epoll_ctl(4, EPOLL_CTL_DEL, 3, 0xc0000f96bc) = -1 EPERM (Operation not permitted)
[pid 204326] write(3, "Cloud,Date,MachineType,Cores,Sin"..., 53) = 53
[pid 204326] close(3) = 0
[pid 204326] exit_group(0) = ?
[pid 204329] <... futex resumed>) = 231
[pid 204328] <... futex resumed>) = ?
[pid 204330] <... futex resumed>) = ?
[pid 204331] <... futex resumed>) = ?
[pid 204327] <... nanosleep resumed> <unfinished ...>) = ?
[pid 204331] +++ exited with 0 +++
[pid 204330] +++ exited with 0 +++
[pid 204329] +++ exited with 0 +++
[pid 204328] +++ exited with 0 +++
[pid 204327] +++ exited with 0 +++
+++ exited with 0 +++

Azure's ultra disk doesn't support ds-v5 and es-v5

From the report:

Azure does not provide a 2500 GB option; we used the average cost of a 2TB option and scaled it to 2.5TB.

If I understand correctly, on azure, a 2.5TB premium disk will cost the same as a 4TB premium disk, while a 2.5TB ultra disk will cost the same as a 3TB ultra disk. The former is the disk size as presented to the virtual machine, the latter is the actual disk size. In this case, it so happens that there is no performance difference between a 2TB and a 4TB premium disk, nor between a 2TB and a 3TB ultra disk, thus the performance numbers should be still fair to other providers. However, the pricing calculation as quoted above can still be misleading.

Going forward, the best approach is probably to use either a 2TB disk or a 4TB disk, to cater to azure.