Tag: performance

Let's Encrypt 升級資料庫伺服器 (AMD YES？)

Let's Encrypt 升級了 MariaDB 資料庫的伺服器 (跑 InnoDB)，特地寫了一篇文章出來講：「The Next Gen Database Servers Powering Let's Encrypt」。

CPU 的部份從本來的 2x Intel Xeon E5-2650 (Total 24 cores / 48 threads) 換成了 2x AMD EPYC 7542 (Total 64 cores / 128 threads)，這點在本來就是 CPU 滿載的情境下改善很大：

而本來的瓶頸一解決，也使得 API 的 latency 直接降下去：

回頭看一下架構，可以看到他們提到沒有使用分散式的資料庫，而是單台 database 硬撐，驗證了即使到了 Let's Encrypt 這種規模，以暴制暴還是很有效的：

We run the CA against a single database in order to minimize complexity. Minimizing complexity is good for security, reliability, and reducing maintenance burden. We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary.

除了 CPU 暴力外，2TB RAM 與 24 顆 NVMe SSD 的搞法也是很讚的，擺明就是用記憶體拼 cache 的量，以及用大量的 NVMe SSD 疊 IOPS。

然後硬體還在成長，看起來暴力解應該會變成以後的基本答案了...

Atlassian 在 ToS 內禁止使用者討論 Cloud 產品的效能

在 Hacker News Daily 上看到的：「Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues (atlassian.com)」，引用的頁面是「Atlassian Cloud Terms of Service」這邊。

翻了下 Internet Archive，看起來在 2018/11/01 生效的版本就有這條了：「20181102013014」。

出自這條：

3.3. Restrictions. Except as otherwise expressly permitted in these Terms, you will not: [...]; (i) publicly disseminate information regarding the performance of the Cloud Products; [...]

這個條文已經生效兩年多了，不過我猜就是被大家批一批還是依舊...

這類條款類似於 Oracle 與 Microsoft 在資料庫系統上面的條款 (可以參考「Is it against license to publish Oracle and SQL Server performance test?」這邊的回答)，看起來除非從法律層級禁止，不然應該只會有愈來愈多公司納入這類條款...

EC2 的 Monitoring 提供更多關於限流的資訊

AWS 對於 EC2 的網路推出了五個新的監控指標：「Amazon EC2 announces new network performance metrics for EC2 instances」。

看起來都是跟限流有關的指標，看起來是在壓榨機器極限時會用到：

The new metrics inform customers in real time of network traffic impacted when instance allowances for inbound and outbound bandwidth, packets-per-second (PPS), connections tracked and PPS to link-local services are exceeded.

需要有最新的 ENA driver 才會提供 (看了一下現有的機器沒出現這些值 XD)：

These metrics are available today in all global commercial AWS regions on instances running the latest version of the Elastic Network Adapter (ENA) driver with support for Linux, Windows ENA driver support will be available soon with version 2.2.2.0.

不另外收費：

They can be accessed from within the instance at no extra cost using simple command line tools.

這個功能在所有 AWS 商業區以及 GovCloud (US) 都已經上線：

Instance Level Network Performance Metrics is available in all AWS Commercial and GovCloud (US) Regions, with the exception of China (Beijing) and China (Ningxia).

先記錄起來就好，一般用法應該都還好...

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式，結合了 Golang 的執行效率與 JavaScript 的操作語法，讓使用者可以很簡單的進行壓力測試，在 Hacker News 上也有蠻正向的反應：「K6: Like unit testing, for performance (github.com/loadimpact)」，我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊，看起來「Load Impact」是公司名稱，「LoadImpact」則是產品名稱，然後現在要改名變成「k6」與「k6 Cloud」：

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念，如同字面上的意義，VU 是虛擬的使用者，就技術上來說，每個 VU 都是在獨立的 JavaScript runtime 裡跑：

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了，所以就不需要一堆 callback & promise 架構，用起來就爽很多：

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼，看起來 JavaScript runtime 這部份是用 Golang 寫的 goja。

文件裡面給了不少範例，像是在「Running k6」這邊有直接給出怎麼壓測，10 個 VU 跑 30 秒：

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面，「samples」這個目錄下有不少範例，可以直接先看過一次從裡面學到不少功能，之後再回去翻一次 manual，應該就會更熟悉...

隨便測了一下還蠻容易上手的，加上有 apt repository 可以直接納入系統管理，看起來應該會放著跑，之後找機會用看看，也許打 API 之類的...

gp3 (Amazon EBS) 的 latency

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

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

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

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.

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

Amazon EBS 的 io2 給了不少新消息...

Amazon EBS 的另外一個新推出的東西，是針對 io2 的改善：

前面兩則消息可以一起看，主要是推出了 EBS Block Express，有著效能上的提昇：

Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.

目前因為是 preview 階段，想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區)，而且需要搭配 r5b 的機器：

The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.

第三則消息則是在講 io2 的 IOPS 的折扣，針對購買 32K IOPS 以上的部份會有 30% 折扣：

Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).

針對前面提到的 preview 版本 (EBS Block Express)，因為可以超過 64K IOPS，這個部份的價錢會更低，再疊一次 30% 的折扣：

Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.

算是要衝效能的人用的，目前平常應該還是會用 gp2 或是 gp3 的 SSD...

Amazon EBS 推出了 gp3

今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。

首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。

每 GB 單位成本比 gp2 低 20%：

Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.

然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：

gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.

但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。

也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。

IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。

轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：

If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.

像是這樣：

但照「Amazon EBS volume types」這邊的列表，gp3 可以是開機硬碟，但是改不過去啊 XDDD

Update：剛剛發現文件被修正了，看起來不能當開機硬碟...

不知道哪邊搞錯了，過幾天看看吧 XDDD

Apple M1 的效能與省電原因

在 Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋，可以當作一種看法：

可以在 Thread reader 上面讀：「Thread by @ErrataRob on Thread Reader App – Thread Reader App」。

看起來 Apple 在規劃的時候就有考慮 x86 模擬問題，所以在記憶體架構上直接實做了對應的模式，大幅降低了當年 Microsoft 在 Surface 上遇到的問題：

3/ The biggest hurdle was "memory-ordering", the order in which two CPUs see modifications in memory by each other. It's the biggest problem affecting Microsoft's emulation of x86 on their Arm-based "Surface" laptops.

4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.

另外一個比較有趣的架構是，Apple M1 上面的兩個 core 有不同的架構，一顆對效能最佳化，另外一顆對效率最佳化：

13/ Apple's strategy is to use two processors: one designed to run fast above 3 GHz, and the other to run slow below 2 GHz. Apple calls this their "performance" and "efficiency" processors. Each optimized to be their best at their goal.

在 wikipedia 上的介紹也有提到這兩個 core 的不同，像是 L1 cache 的差異 (128KB 與 192KB)，以及功耗的差異：

The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, providing a configuration similar to ARM big.LITTLE and Intel's Lakefield processors. This combination allows power-use optimizations not possible with Apple–Intel architecture devices. Apple claims the energy-efficient cores use one tenth the power of the high-performance ones. The high-performance cores have 192 KB of instruction cache and 128 KB of data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB instruction cache, 64 KB data cache, and a shared 4 MB L2 cache. The Icestorm "E cluster" has a frequency of 0.6–2.064 GHz and a maximum power consumption of 1.3 W. The Firestorm "P cluster" has a frequency of 0.6–3.204 GHz and a maximum power consumption of 13.8 W.

再加上其他架構上的改善 (像是針對 JavaScript 的指令集、L1 的提昇，以及用 TSMC 最新製程)，累積起來就變成把 Intel 版本壓在地上磨蹭的結果了...

在 Hacker News 上看到 Raspberry Pi 400 使用心得

在 Hacker News 看到 Raspberry Pi 400 的使用心得：「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」，先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400，主要就是一台 Raspberry Pi 4 Model B 的主機，但跟鍵盤整合在一起。

在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇)，主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD)，這一直都是 Raspberry Pi 上面用 SD card 的問題，看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。

If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.

另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度，不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向，本來就有取捨，不太可能什麼都做進去...

回到作者的心得，雖然 USB3 轉 SSD 看起來 i/o 速度快不少，但我好像主要不是遇到 i/o 速度問題，反倒是最近 chromium 的硬體解碼好像有些進度，也許看影片有機會用硬體處理 (至少一部份？)，希望至少可以輕鬆看 1080p60 啊...

RDS 推出 ARM 版本

Amazon RDS 推出了 ARM 的版本：「New – Amazon RDS on Graviton2 Processors」，包含了 MySQL、MariaDB 與 PostgreSQL 的版本都有支援，不過看起來需要比較新版的才能用：

You can choose between M6g and R6g instance families and three database engines (MySQL 8.0.17 and higher, MariaDB 10.4.13 and higher, and PostgreSQL 12.3 and higher).

官方宣稱可以提供 35% 的效能提昇，考慮費用的部份會有 52% 的 c/p 值提昇：

Graviton2 instances provide up to 35% performance improvement and up to 52% price-performance improvement for RDS open source databases, based on internal testing of workloads with varying characteristics of compute and memory requirements.

對於 RDS 這種純粹就是個服務的應用來說，感覺應該不會有什麼轉移成本，只要測過沒問題，換過去等於就是現賺的。看起來等 RI 約滿了就可以切...