CPU Core 之間溝通的時間成本

Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇,專案在「Measuring CPU core-to-core latency」這裡,看起來是個有趣的研究,測試許多不同 CPU 內,跨 core 之間溝通的時間花費。

依照專案的說明,測試的方式是利用 cache coherence 來來量測:

We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

裡面已經測了很多不同的 CPU,然後可以看到一些有趣的結果。

像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組,大家還蠻好奇 CPU #8 到底是怎麼一回事,跨 core 溝通的 latency 特別低,還特別找了 CPU 的 die 圖片看看:

另外一個是 AWS 上的 c6a.metal,機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」,可以看到被分成了六個區塊:

接下來在 ARM 平台,在更多 CPU core 的 c7g.16xlarge 上,機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」,會看到更多不平均的現象:

早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」,但可以看到很不一樣的 latency pattern:

大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸,導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。

Amazon EFS 的效能提昇

AWS 宣佈他們將 Amazon EFS 的 latency 大幅降低以提昇效能:「Amazon Elastic File System Update – Sub-Millisecond Read Latency」。

Linux 上一般是用 NFS 掛 EFS,個位數的 ms 的確對於效能影響超大,現在宣稱讀取的部份降到 0.6ms,應該會有蠻明顯的感覺:

Up until today, EFS latency for read operations (both data and metadata) was typically in the low single-digit milliseconds. Effective today, new and existing EFS file systems now provide average latency as low as 600 microseconds for the majority of read operations on data and metadata.

然後不另外收費:

This performance boost applies to One Zone and Standard General Purpose EFS file systems. New or old, you will still get the same availability, durability, scalability, and strong read-after-write consistency that you have come to expect from EFS, at no additional cost and with no configuration changes.

另外就是過去幾個禮拜他們把現有的 EFS 都轉移過去了:

We “flipped the switch” and enabled this performance boost for all existing EFS General Purpose mode file systems over the course of the last few weeks, so you may already have noticed the improvement. Of course, any new file systems that you create will also benefit.

不過 EFS 另外一個問題就是貴炸,用錢換方便...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month,另外 CloudFront 則是大幅增加,從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月),另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上,另外先對預設的 /* 調整成 no cache,然後針對 /wp-content/* 另外加上 cache 處理,跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency,從 HiNet 連到免費版的 Cloudflare 會導去美國,用 CloudFront 的話就會是台灣了:

另外一方面,這樣國際頻寬的部份就會走進 AWS 的骨幹,比起透過 HiNet 自己連到美國的 PoP 上,理論上應該是會快一些...

AWS 區域間的連線測試

Hacker News 首頁上看到「AWS Latency Monitoring」這個,看起來是常態性在所有的機房都開機器一直測試蒐集資料,就可以直接拉出來看...

有常見的 p50 與 p99 資訊,對於在規劃架構的時候還蠻有用,在「mda590/cloudping.co」這邊可以看到他是用 LambdaDynamoDB 的 endpoint 測試。

好像沒有 packet loss rate 的資訊,這個也蠻重要的...

AWS 大阪區開放

AWS 大阪區開放給大家使用了,而且有標準的三個 AZ 可以用:「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。

大阪區因為之前就已經有機房 (附加在東京區),所以對應的 routing 看起來不算太差,但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency,分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。

另外測了其他的 ISP,有些上日本的點是以東京為主,反而會多繞了一圈,大阪區的 latency 會比較高。

不過如果放遠來說,東京大阪的直線距離大約是 400km,光纖的傳輸速度大約是光速的 2/3,所以單趟大約差了 2ms,如果有機會最佳化的話應該有機會擠出 4ms 出來?

然後是 EC2Pricing 頁面,上面還是寫 Asia Pacific (Osaka-Local),無法確定是新資料還是舊資料,但以往的慣例應該是更新了...

對照文章裡有提到支援的機器,目前看起來還沒有很齊,像是目前都還沒有 AMDARM 架構的機器,另外也沒有 GPU 類型的機器:

The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.

就支援的類型隨意挑了幾個 instance type 比較,翻了一下價錢看起來跟東京的一樣。

整體看起來,如果是有考慮到異地的需求是可以考慮,另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來),但既有的服務應該不需要急著搬...

Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology:「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題,透過 Cloudflare 自家的骨幹網路,最佳化 latency & bandwidth & packet loss 產生的問題:「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了,主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料,而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server,就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好:就算是 Windows Update 或是 iOS 更新這種基數超大的量,一開始也許會慢一點,但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm,讓 edge server 都有 cache 後再上線,這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了,因為會一直產出新的內容 (之前玩的是走 HLS,所以會一直有新的 .ts 檔生出來),沒辦法先 pre-warm,這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務,所以需要 CDN 系統在中間疊一層 cache server,這個功能在各家 CDN 業者都有,只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate,這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1),而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+,相對於後端的壓力可以降到 50:1 到 100+:1。

AWSCloudFront 也有類似的架構,叫做 Regional Edge Caches:

不過這兩種架構都有一些缺點,像 Akamai 需要自己指定 cache server 的節點,這樣就不容易動態調整,或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的,就會遇到像是 origin server 與 edge server 都在台灣,但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡),產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache),看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier,不需要使用者額外設定。

不過一般網站應該還好,主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

gp3 (Amazon EBS) 的 latency

昨天把手上所有的 Amazon EBSgp2 換到 gp3 了:「Amazon EBS 的 gp3 可以用在開機磁碟了」,今天早上來看一下狀態,整體看起來是還 OK,不過有些地方值得注意的,像是標題寫到的 latency。

我抓了跑 GitLab 的機器來看,可以很明顯看到讀寫的 latency 都變高了:

AWS 又有提到這些數字資料有經過轉換,看起來是 gp2gp3 的數字意義本來就不一樣,所以他必須想辦法轉換,所以也有可能是因為這個轉換導致的?

This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.

不過其他的數字倒是沒什麼變化,系統的負荷量其實也還好,就先丟著跑...

CloudFront 支援 TLS 1.3

看到 AWS 的公告,宣佈 CloudFront 支援 TLS 1.3:「Amazon CloudFront announces support for TLSv1.3 for viewer connections」。

預設會自動啟用:

TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections.

對使用者最大的差異應該還是改善 first byte 的時間 (主要是因為 handshake 時間縮短),這點 AWS 的人也有提到在內部測試時,美國區的改善情況:

In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

在 latency 更高的地區應該也會有大幅改善...

SpaceX Starlink 的延遲與速度

SpaceXStarlink 已經有些人開始在測試了,在 Speedtest.net 上也已經有人挖到資料,可以看出他的延遲與速度了:「SpaceX Starlink speeds revealed as beta users get downloads of 11 to 60Mbps」。

報導的資料主要是從 Reddit 上的拉出來的,如果要看原始的資料,可以參考「List of Confirmed Starlink Speed Tests」這篇列出來的連結。

延遲可以低到 20ms 左右,不過比較常見是 30ms~40ms,高的時候可以看到 90ms 左右,這樣看起來頗有競爭性的,下載速度看起來也還不錯...

目前看起來都是加州地區的測試,查了資料看起來是目前開放的區域有限 (加拿大南部與美國北部),之後可以看開放其他地區的情況。

另外未來如果更多衛星打上去,網路的品質應該會更好,不過對天文學家看起來是場災難,光害的問題看起來很嚴重,像這張曝兩秒的照片就可以看出來這六顆的情況:(出自「File:Starlink 6 satellites.jpg」)

AWS Lambda 的 Provisioned Concurrency

AWS Lambda 推出了 Provisioned Concurrency,降低冷啟動所需要的時間以確保效率:「New – Provisioned Concurrency for Lambda Functions」。

看 benchmark 的資料就很清楚,可以避免冷啟動所產生的延遲:

這邊也可以看出來就算是冷啟動,大約也是多個一秒多。如果這個延遲是需要被處理的,就可以考慮用 Provisioned Concurrency 了。

價位上是依照保留的量:

You only pay for the amount of concurrency that you configure and for the period of time that you configure it. Pricing in US East (N. Virginia) is $0.015 per GB-hour for Provisioned Concurrency and $0.035 per GB-hour for Duration. The number of requests is charged at the same rate as normal functions. You can find more information in the Lambda pricing page.

不過如果量再更大,而且考慮成本,應該會考慮改回傳統的架構,用多台 EC2 instance 跑...