Tag: performance

AWS 推出 c7g 機種

AWS 在 Amazon EC2 產品線上推出了新一代的 ARM 產品，AWS Graviton3 架構，c7g 系列機種：「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」。

Graviton3 宣稱比 Graviton2 多 25% 的一般性效能，以及多了一倍的浮點效能，還有 DDR5 的頻寬優勢：

Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.

在「FreeBSD on the Graviton 3」這邊也可以看到一些效能數據 (雖然是跑在 FreeBSD 上)，可以看到基本上符合 AWS 的宣稱。

目前只有 us-east-1 與 us-west-2 有這個機種，不過 Graviton 系列一直都是 AWS 的強主打項目，其他區域應該很快就會看到：

C7g instances are initially available in US East (N. Virginia) and US West (Oregon) AWS Regions; other Regions will be added shortly after launch.

價位上比 c6g 貴了一些，在 us-east-1 上 c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour，而 c6g.16xlarge 是 US$2.176/hour，大約貴了 6.6%，但如果是 CPU bounded 的應用來說，應該還是蠻划算的。

另外一方面是等後續的 m7g 與 r7g 系列出現...

GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了：「GOV.UK drops jQuery from their front end.」，Hacker News 上的討論也可以看一下：「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因，第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂，像是：

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類)，可以注意 jQuery 1.0 就已經把基本界面都弄出來了，而 jQuery 1.0 是 2006 年八月出的，另外 IE7 是在 2006 年十月出，也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為，像是經典的 attachEvent (出自 DOM events)：

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說，jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力，這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少，而且就算有了 querySelectorAll()，Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象，jQuery 其實也帶入了不少好用的 pattern，其中一個是 fluent interface 讓人寫起來很舒服：(這個範例只是要介紹 fluent interface，不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理：

$('#foo').css('width: 100px;');

與這樣比較：

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年，負面的部份已經大幅改善了，所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果：

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話，~10% 左右的 performance 改變比預期中少很多耶？可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考，如果可以用 jQuery 降低開發的瓶頸，我還蠻偏好就拿 jQuery 進來用...

Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」，可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台：「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構，每台機器可以堆五台 replica：

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本：

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication，這種搞法還蠻有趣的 XDDD

Brendan Gregg 加入 Intel

先前有提到 Brendan Gregg 離開了 Netflix 的事情：「Brendan Gregg 離開 Netflix」，剛剛看到他發表他去 Intel 的消息：「Brendan@Intel.com」。

看起來是任何跟 performance 有關的都可以碰，但主力會放在跟 cloud 相關的產品線上：

I'm thrilled to be joining Intel to work on the performance of everything, apps to metal, with a focus on cloud computing.

不知道起頭會碰什麼東西，也許先花幾個月熟悉？

這個月 GitHub 的不穩問題，都是 mysql1 這個 cluster 的鍋...

GitHub 針對了這個月的四次 downtime 說明，大致上都跟 mysql1 這組 cluster 有關：「An update on recent service disruptions」，這是 Keith Ballinger 發的文章，找了一下掛的頭銜是 SVP of Engineering at GitHub。

文章裡提到的 mysql1 在「Partitioning GitHub’s relational databases to handle scale」這邊可以看到一些資訊 (我在「GitHub 的 MySQL 架構與數字」這邊也有提到)，基本上有 ProxySQL + Vitess 兩套方案在 scale，但可以看出來主資料庫本身還是有很大的 loading 在上面跑。

這次的問題是 mysql1 看起來這次遇到了效能上的瓶頸，不過還是沒找到原因，這可以從這幾次的說明看出來，從第一次的 outage：

The incident appeared to be related to peak load combined with poor query performance for specific sets of circumstances.

第二次的：

The following day, we saw the same peak traffic pattern and load on mysql1. We were not able to pinpoint and address the query performance issues before this peak, and we decided to proactively failover before the issue escalated.

第三次的：

While we had reduced load seen in the previous incidents, we were not fully confident in the mitigations.

In this third incident, we enabled memory profiling on our database proxy in order to look more closely at the performance characteristics during peak load.

到最近第四次的：

In order to reduce load, we throttled webhook traffic and will continue to use that as a mitigation to prevent future recurrence during peak load times as we continue to investigate further mitigations.

可以看到基本上還沒完，之後再遇到問題時應該還是會把 webhook traffic 拿出來開刀...

Mac 上 sprintf 的 scalability 問題

在 Hacker News 上看到個有趣的 scalability 問題，在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題：「Curious lack of sprintf scaling (aras-p.info)」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題，要注意到這邊的 Y 軸是對數比例：

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」)：

然後用了 Instruments 跑 profiling 找問題，可以看到看起來跟 locale 有關：

一般的情況下應該不會是問題，但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法，包括了 stb_sprintf 當作替代品，以及 {fmt} 作為 iostreams 的替代品，然後另外是利用 to_chars 來解決，如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程，對於開發者來說，一般性的重點還是在 profiling，找到對的問題然後再往下提出解法...

Amazon EFS 效能提昇的一些討論

上一篇「Amazon EFS 的效能提昇」提到 Amazon EFS 的效能提昇，在 Hacker News 上看到 Amazon EFS 團隊的 PMT (Product-Manager-Technical) 出來回一些東西：「Amazon Elastic File System Update – Sub-Millisecond Read Latency (amazon.com)」，搜尋 geertj 應該就可以看到他回的東西了...

像是即使是 Jeff Barr 發表這篇文章，也還是經過 legal team 的同意才能發表：

(PMT on the EFS team).

Yes, the wordings are carefully formulated as they have to be signed off by the AWS legal team for obvious reasons. With that said, this update was driven by profiling real applications and addressing the most common operations, so the benefits are real. For example, a simple WordPress "hello world" is now about 2x as fast as before.

另外這次的效能提昇是透過 cache 層達成的：

I'm the PMT for this project in the EFS team. The "flip the switch" part was indeed one of the harder parts to get right. Happy to share some limited details. The performance improvement builds on a distributed consistent cache. You can enable such a cache in multiple steps. First you deploy the software across the entire stack that supports the caching protocol but it's disabled by configuration. Then you turn it for the multiple components that are involved in the right order. Another thing that was hard to get right was to ensure that there are no performance regressions due to the consistency protocol.

然後在每個 AZ 都有 cache：

The caches are local to each AZ so you get the low latency in each AZ, the other details are different. Unfortunately I can't share additional details at this moment, but we are looking to do a technical update on EFS at some point soon, maybe at a similar venue!

另外看起來主要就是 metadata cache 的幫助：

NFS workloads are typically metadata heavy and highly correlated in time, so you can achieve very high hit rates. I can't share any specific numbers unfortunately.

還是有很多細節數字不能透漏，但知道是透過 cache 達成的就已經可以大致上想像後面是怎麼弄出來的了...

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 另外一個問題就是貴炸，用錢換方便...

Amazon EC2 推出 c6a 的機器

Amazon EC2 以新的 AMD 架構 (雖然也推出一陣子了) 的機器推出 c 系列的機種，代號為 c6a：「New – Amazon EC2 C6a Instances Powered By 3rd Gen AMD EPYC Processors for Compute-Intensive Workloads」。

價位上與 c5a 相比便宜一點點，是真的一點點：在 us-east-1 的 c5a.24xlarge 是 US$3.696/hr，而 c6a.24xlarge 是 US$3.672，差 0.65% 左右... (千分之六點五 XD)

所以宣稱的 15% 基本上都是從 CPU 效能提昇貢獻的：

Up to 15 percent improvement in compute price performance.

然後機器可以提供的範圍比較大台，c5a 最大到 c5a.24xlarge，而 c6a 支援了 c6a.32xlarge 與 c6a.48xlarge。

目前亞洲區都還沒上，要再等等了：

C6a instances are available today in three AWS Regions: US East (N. Virginia), US West (Oregon), and EU (Ireland). As usual with EC2, you pay for what you use. For more information, see the EC2 pricing page.

另外這次推出後，EC2 的機種超過 500 種了，主要是靠排列組合弄出來的：

PS – With the launch of C6a instances there are now officially more than 500 Amazon EC2 instances for customers to choose from!

Raspberry Pi OS 64-bit 與 32-bit 的效能差異

前幾天提過「Raspberry Pi OS 64-bit 版本正式推出」，而 Phoronix 實際拿正式版測試 64-bit 與 32-bit 的系統差異了，在「Raspberry Pi OS 32-bit vs. 64-bit Performance」這邊可以看到每一個測試項目的結果。

測試的硬體是 Raspberry Pi 400，這台機器基本上就是 4GB 版本的 Raspberry Pi 4 加上週邊配件：

Using a Raspberry Pi 400 keyboard computer with 4GB of RAM, I ran some fresh benchmarks of Raspberry Pi OS in its default 32-bit build and then again with the new 64-bit build.

先講結果，在 Phoronix 的 33 個測試裡面，64-bit 全部都比 32-bit 好，而且是很明顯的差異：

Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%. See all the 32-bit vs. 64-bit Raspberry Pi benchmarks over on OpenBenchmarking.org.

之前 64-bit OS 還在 beta 的時候就已經知道這個情況了，所以不會覺得太意外。當時提出的解釋是指令集的差異，aarch64 提供的指令集比 armv6 有效率多了，這點在 2016 年的文章「64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions」這邊可以看到說明。

所以正式版出來以後，只要硬體有支援，基本上都建議裝 64-bit OS 了...