Tag: performance

Reddit 當初對 Google 搜尋引擎的客製化設計

在 Hacker News 上看到的討論，裡面剛好有 Reddit 第一個雇用的工程師，Jeremy Edberg 的留言：「Reddit is taking over Google (businessinsider.com)」。

在 id=40068381 這邊提到了不少東西，首先是把 title 放進 url 裡面的作法：

To this day, my most public contribution to reddit is that I wrote the code to put the title of the post in the URL. That was done specifically for SEO purposes.

這個在 Google Webmasters (現在叫做 Google Search Console) 也針對 Reddit 處理，將速率強制設為 Custom，不讓 Reddit 的人改：

It was pretty much the only SEO optimization we ever did (along with a few DOM changes), because shortly after that, Google basically dedicated engineering effort specifically to crawling reddit. So much so that we lost the "crawl rate" button in our SEO admin page on Google, it was just set to "Custom".

後續還要針對 Google 的抓取在 load balancer 上把流量拆開處理，不然 crawling pattern 與一般使用情境很不一樣，會造成 cache 的效率極度低落：

I had to stand up a fleet of app servers and caches and databases, and change the load balancers so that Google basically had their own infrastructure (although we would shunt all crawlers there). Crawler traffic was very different than regular traffic -- it looked at pages more than two days old, something humans rarely did at the time. It would blow out every cache (memory, database, disk, etc.). So we put them on their own infra to keep them from killing the rest of the site.

這些算是頗有趣的經驗？

Java 21 的 ZGC 在 Netflix 的效果

在 Hacker News 上看到連結「Bending pause times to your will with Generational ZGC (netflixtechblog.com)」，發現這篇還沒整理：「Bending pause times to your will with Generational ZGC」，裡面講的東西都有圖有數字 (i.e. Y 軸)，作者是 Danny Thomas。

在這之前他們就已經知道 GC pause 是延遲的重要來源，會導致 timeout & retry：

In both our GRPC and DGS Framework services, GC pauses are a significant source of tail latencies.

That’s particularly true of our GRPC clients and servers, where request cancellations due to timeouts interact with reliability features such as retries, hedging and fallbacks.

第一張圖拉出來的資料是 error rate，白色是上個禮拜的資料，紫色是這個禮拜的資料，而從 G1GC 切到 ZGC 是在 2023/11/16 發生的：

可以看到很明顯的 error rate 改變：尖峰從 2k 下降到大約 0.3k，大約是原來的 1/6 到 1/7 的下降。

第二張圖是 GC 的時間：

可以看到 G1GC 還是偶而會撞到 2 秒，發生時平均值也都還是會 >100ms，切到 ZGC 後直接降到個位數 ms 等級了。

第三張圖是 memory overhead 的部分：

從圖上可以看到上週與本週的對比，導入 ZGC 後記憶體的使用量下降了，不過文裡面倒是沒解釋這點，反而提到 ZGC 比起 G1GC 有個固定的 3% overhead：

ZGC has a fixed overhead 3% of the heap size, requiring more native memory than G1. Except in a couple of cases, there’s been no need to lower the maximum heap size to allow for more headroom, and those were services with greater than average native memory needs.

第四張則是 Huge Pages 的差異，這邊要注意這張圖的 Y 軸不是從 0 計算：

可以看到在開 Huge Pages 後，在 RPS (request per second) 不變的情況下 CPU 使用率是有下降的，大約從 50% 降到 45% 左右，不過這張圖的時間跨度有點少，應該是要拉長一點的圖... 不過既然被提出來了，就假設 Netflix 內看起來應該是有這個趨勢，只是抓圖的時候懶了點？

整體算是大成功？

關於 GitLab 的 SQL 設計

今天「My notes on Gitlab's Postgres schema design (2022) (shekhargulati.com)」這篇上 Hacker News 首頁 (看起來因為是在 pool 的關係，在第一頁卡很久...)，文章「My Notes on GitLab Postgres Schema Design」是作者在 2022 年七月的時候分析了 GitLab 的 structure.sql 的資料庫設計整理出來的心得 & 感想，裡面有不少東西，不過這邊想補充個背景知識 (姿勢？)：

RDBMS 在系統架構裡面，相較於其他的元件，是個很難 scale out 的東西 (i.e. 加更多機器得到更多效能)，所以遇過 scalability 問題的架構師，會很習慣避開在 RDBMS 上面跑各種功能，有其他方式可以做的就拆出去用容易 scale out 的工具來做，非不得已才上 RDBMS。

而就算要塞進 RDBMS 裡的資料，能省的還是要省，畢竟宣稱自動幫你處理資料庫 scale out 的技術 (像是 CockroachDB 與 TiDB) 其實沒想像中萬能，還是需要開發者改寫以前大惡搞的 SQL query (一個 terminal 列不完那種)。

而你心裡也有底，如果 scale out 不是條好的路，那麼只好 scale up (i.e. 加大機器的 CPU & RAM)，而 scale up 總是有極限，真的遇到自己被迫要處理 sharding 的時候，DBOps/DBA 與 Dev 的臉都很臭... (一堆 JOIN 要改成拉回 application 端自己湊，或是有 ProxySQL 這種東西幫你處理，但是發現 ProxySQL 去後面資料庫拉太多資料幫你組反而很慢 !@#$%)

但另外一方面，現在已經不是 2005 年 64GB RAM 的伺服器是個天價的年代... 硬體的成長已經長到在 AWS 雲端上面可以租到給 SAP 用的 24TB RAM 的機器 (u-24tb1.112xlarge)，而地端找個 server 也都有 15TB RAM (POWEREDGE R940)，所以很容易把所有資料都塞到記憶體裡面搞，加上 NVMe 的讀寫速度比以前 HDD disk 快多了。

記得這兩件都是現實，然後再回來看文章內容與其他的討論，用不同的現實就會有不同的想法出現。

GitLab 的設計有他當時的限制以及想法，這些是外面的人看不到的，也就不好批評對錯。

PHP 8.3 相比於 PHP 8.2 的效能提升

找資料的時候意外發現 PHP 8.3 相對於 PHP 8.2 的效能提升好像不算小？目前看到這兩個地方有提到：

前面那篇的 benchmark 數據可以看出來愈大愈複雜的框架，提升的效能就愈多：

  • 乾淨的 WordPress 從 158 rps 成長到 169 rps，大約 7% 的增加。
  • 如果是 WooCommerce 的話從 49 rps 到 58 rps，大約是 18.4%。
  • 接著 Laravel 則是從 670 rps 到 925 rps，提升了 38.1%。
  • 而 Drupal 則是 941 rps 到 1432 rps，提升了 52.2%。

在「Make your app faster with PHP 8.3」這邊提到了 PHP 8.3 改善了很多關於效能的項目。

首先提到的是 JIT 的改善：

The Just-In-Time (JIT) compiler has been further optimized for better efficiency. The execution of scripts is faster and consumes less CPU time. This is especially beneficial for resource-intensive tasks.

然後是 opcode 這邊的改善：

PHP has refined how it handles opcodes (the instructions in the PHP bytecode). Version 8.3 uses more efficient ways to interpret and execute these opcodes. This reduces the execution time of scripts.

然後 GC 機制也改善了：

PHP 8.3 enhances the garbage collection mechanism, which is responsible for freeing memory occupied by unused objects. This results in more efficient memory usage and can significantly improve performance for memory-intensive applications.

array 的改善：

Other improvements include optimizations for handling arrays and an enhanced type system.

對於複雜的應用就很容易都受惠，然後就有頗大的提升...

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡，兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet，這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet，但我希望 VM 是走社區網路，所以用 bridge mode 設定到網卡上，用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到，前幾天用 Line 傳照片的時候很慢 (之前就有發生了，一直忘記去追問題)，花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢，這點可以從 Speedtest 的測試結果看到：

先講最後的結論，在交叉測了很多組合後，我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled：

回到當時抓問題的情況，當時先用筆電與 host 測試都沒看到問題，所以看起來應該是 VM 裡面的狀況，但不確定是什麼情況，畢竟不是斷掉...

由於下載速度正常，只有上傳速度卡住，一開始想到的是跟 MTU 相關的問題，所以找了指令降到 1400 後測試，還是一樣...

後來先把 VM 的網路改成 NAT，再測試上傳速度就正常了...

接著想要換個網路卡類型看看，結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了，但想說先去看看 Windows 10 網卡設定裡面的設定，結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗？)。

然後一關就正常了，交叉再開關兩次確認這個參數有影響，就肯定這個 workaround 應該是有效了...

另外在自己找完問題後，在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2 對 t4g.small 提供了 free tier 方案 (到今年年底)，blog 主機剛好從 t4g.micro 改成用 t4g.small，到年底前可以看看有沒有 t5g 或是類似的主機出來：「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外，我在檢查時才發現 PHP 的 opcache 的 cache 使用量也超過預設值 128MB 了，改成 192MB 後看起來 CPU usage 也有下降一些：

這點算是先前沒注意到的，上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension)，還有一個自己寫的小東西，這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了：

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance，然後透過 AWS Chatbot 接到自己的 Slack 上，至少之後有狀況的時候會主動通知。

arXiv 上了 Fastly CDN

看到 arXiv 宣佈上了 Fastly 的 CDN：「Faster arXiv with Fastly」。

翻了一下 arxiv.org 的 DNS record，可以看到現在是這樣：

;; ANSWER SECTION:
arxiv.org.              10      IN      A       151.101.131.42
arxiv.org.              10      IN      A       151.101.3.42
arxiv.org.              10      IN      A       151.101.67.42
arxiv.org.              10      IN      A       151.101.195.42

用 mtr 測試，看起來 HiNet 過去的 routing 還是進到新加坡。

不過 static.arxiv.org 是在 CloudFront 上：

;; ANSWER SECTION:
static.arxiv.org.       3600    IN      CNAME   daa2ks08y5ls.cloudfront.net.
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.100
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.29
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.88
daa2ks08y5ls.cloudfront.net. 60 IN      A       13.35.35.127

依照官方的說明看起來還在換，只是不知道已經在 CloudFront 上的 (像是上面提到的 static.arxiv.org) 會不會換過去：

That includes our home page, listings, abstracts, and papers — both PDF and HTML (more on that soon).

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇：「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」，原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報，提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal()，透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal()，直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy() 與 memmove() 類的地方，算是很常見備用到的功能，這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到：「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」，所以後續應該也會有些改善的討論...

在 Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這，上游的 glibc 也有對應的追蹤：「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息，因為 patch space 的大小限制，AMD 可能無法提供 CPU microcode 上的 patch，直接解決問題：

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround，回到原來沒有 FSRM 的方式處理：

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境，得拿出不同的 profiling 工具出來用，所以也還蠻值得看過一次有個印象：

一開始的 timeit 算是 Python 裡面簡單的 benchmark library：

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑)，查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+)：

再來是用 strace 追問題，這個算是經典工具了，可以拿來看 syscall 被呼叫的時間點：

到後面出現了 perf 可以拿來看更底層的資訊，像是 CPU 內 cache 的情況：

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式，不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析：

而文章裡的則是可以看到已經到 assembly 層級了：

差不多就這些...

AWS 推出 Amazon S3 Express One Zone

AWS 推出了以效能為導向的 Amazon S3 Express One Zone：「Announcing the new Amazon S3 Express One Zone high performance storage class」。

從名字裡的 One Zone 可以看到這是只有在一個 AZ，主打超低 latency：

The new Amazon S3 Express One Zone storage class is designed to deliver up to 10x better performance than the S3 Standard storage class while handling hundreds of thousands of requests per second with consistent single-digit millisecond latency, making it a great fit for your most frequently accessed data and your most demanding applications.

但費用相當貴，以 us-east-1 來看的話是 $0.16/GB/mo，如果拿其他一些 storage 方案來比，可以看到非常大的差距：

  • S3 Standard：$0.023/GB/mo
  • General Purpose SSD (gp3)：$0.08/GB/mo
  • General Purpose SSD (gp2)：$0.1/GB/mo

可以猜測後面應該全是 NVM 之類的 storage (不過文章裡沒有提到)。

這次的 Amazon S3 Express One Zone 也多出了很多特別的限制。

首先是新的 bucket type，在這個 bucket type 下面 ListObjectsV2 呼叫就必須以 / 結尾 (這暗示後面的資料處理有對這點 optimization)，另外傳回的資料不保證順序了：

The path delimiter must be “/“, and any prefixes that you supply to ListObjectsV2 must end with a delimiter. Also, list operations return results without first sorting them, so you cannot do a “start after” retrieval.

另外看起來是在 AZ 裡面直接認證，所以有新的 authentication model：

The new CreateSession function returns a session token that grants access to a specific bucket for five minutes.

然後 bucket naming 因為有後處理，在命名上不需要在整個 AWS 是唯一的 (因為被加料了)：

Directory bucket names must be unique within their AWS Region, and must specify an Availability Zone ID in a specially formed suffix. If my base bucket name is jbarr and it exists in Availability Zone use1-az5 (Availability Zone 5 in the US East (N. Virginia) Region) the name that I supply to CreateBucket would be jbarr--use1-az5--x-s3.

另外資料還是可以在同一個 region 下跨 AZ 存取，而且同一個 region 下面的 compute resources (像是 EC2) 不收傳輸費用：

Although the bucket exists within a specific Availability Zone, it is accessible from the other zones in the region, and there are no data transfer charges for requests from compute resources in one Availability Zone to directory buckets in another one in the same region.

費用的部分還有個比較特別的但書，超過 512KB 的 request 會需要額外收費：

You pay an additional per-GB fee for the portion of any request that exceeds 512 KB. For more information, see the Amazon S3 Pricing page.

主要是給自己開發的應用程式用的，現有的 framework 大多都有利用 batch & buffering 的技巧降低 latency 所帶來的效能影響。

平常應該是用不太到，但就有個印象，真的在架構設計上跑不掉的時候有個選擇...

FreeBSD 14.0 對比於 13.2 有顯著的效能提升

在 Hacker News 上看到「FreeBSD 14.0 Delivering Great Performance Uplift (phoronix.com)」這篇，原文在「FreeBSD 14.0 Is Delivering Great Performance Uplift & Running Well In Early Tests」這邊。

測試平台是 AMD EPYC™ 8534P (64 cores & 128 threads)，是個今年九月才推出的 CPU，另外底層 filesystem 是跑 ZFS。

翻了一輪測試的資訊，幾乎是所有的項目都有提升 (少數幾樣有些微退步)，但以 Phoronix 的測試計算，整體計算起來有 18% 的提升，對於 OS 升級帶來的提升算是蠻巨大的：

Across the span of five dozen benchmarks carried out on this AMD EPYC 8534P server of FreeBSD 13.2 vs. FreeBSD 14.0, the newly-released FreeBSD 14 was on average 18% faster than its predecessor. Not bad for a simple OS upgrade. I've been seeing very healthy gains on other x86_64 servers tested so far while due to hardware availability haven't yet tried any AArch64 servers.

依照他的說明，後續會有跟其他 Linux distribution 的比較，到時候可以回來再看看：

I'll be running more FreeBSD 14.0 server benchmarks shortly along with following that up by looking at the FreeBSD 14.0 performance against the latest leading Linux distributions. In any event I'm quite happy thus far with the performance and experience in my FreeBSD 14.0 testing.

回頭看報告裡面比較特別的部分，一個是 OpenSSL 的部分有下滑一些，這點應該跟版本更新有關，在 FreeBSD 14.0 的 Release Notes 裡面有提到大版本升級：

OpenSSL has been upgraded to version 3.0.12. This is a major upgrade from version 1.1.1, which has reached its end of life. Many components of the base system use a backward-compatible API, but will be migrated later. aa7957345732 930cec16d9ee b077aed33b7b (Sponsored by The FreeBSD Foundation)

另外一點是在 Page 4 裡面，可以看到 PostgreSQL 16 的效能提升非常明顯，無論是 TPS 還是 latency 都有非常巨大的改善。