performance

Hacker News

早上看到「Tell HN: Thank you for not redesigning Hacker News」這篇，作者在網路速度受限的地區，上各種網站幾乎都不會動，但 Hacker News 沒有改用一堆前端框架，而是保留使用 HTML 反而讓頁面維持極小：

I’m currently in a country with low speed internet and the entire ‘modern’ web is basically unusable except HN, which still loads instantly. Reddit, Twitter, news and banking sites are all painfully slow or simply time out altogether.
To PG, the mods and whoever else is responsible: thank you for not trying to ‘fix’ what isn’t broken.

順手開了一下網路工具來看，發現單一元件最大的居然是 favicon XDDD：

照 Wikipedia 上列出來的相容性，如果只支援 IE11+ 的話，看起來可以改用 PNG，大小就已經有明顯的改善了：

-rw-r--r-- 1 gslin staff 7527 Sep  2 09:50 favicon.ico
-rw-r--r-- 1 gslin staff 2598 Sep  2 09:51 favicon.png

StackOverflow 講 cache 的文章...

這篇是 StackOverflow 在講 cache 的文章，裡面不是什麼新東西，只是看到有趣的項目所以拿出來講：「How Stack Overflow Caches Apps for a Multi-Tenant Architecture」。

在講 cache 前通常都會說明各種儲存空間速度的差異，但裡面混了一個奇怪的東西：

L1: 1.3ns
L2: 3.92ns (3x slower)
L3: 11.11ns (8.5x slower)
DDR4 RAM: 100ns (77x slower)
NVMe SSD: 120,000ns (92,307x slower)
SATA/SAS SSD: 400,000ns (307,692x slower)
Rotational HDD: 2–6ms (1,538,461x slower)
Microsoft Live Login: 12 redirects and 5s (3,846,153,846x slower, approximately)

裡面混了一個不是 storage 的東西進去比較，你們是對 Microsoft 的帳號系統有多不爽 XDDD

另外他們列出了目前 Redis 的使用情況：

For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
Our Redis physical servers have 256GB of memory, but less than 96GB used.
1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
124,415,398 active keys (422,818,481 including replicas)
Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)

然後更長的版本可以在作者自己的 blog 上讀到，裡面講到的 cache invalidate (purge) 這部份有談到一些他們的作法：「Stack Overflow: How We Do App Caching - 2019 Edition」。

操作 S3 Command Line 的工具

在朋友的 Facebook 上看的東西：「S5cmd for High Performance Object Storage」。會想要寫這篇是因為看到 s4cmd 跟 s5cmd 這兩個工具的命名而笑出來：

不過這篇也可以看到差異，s3cmd 是自己用 Python 刻所有東西，s4cmd 還是用 Python，但是因為 boto3 而快了不少，而 s5cmd 則是改用 Golang 寫，並且採用多個 TCP connection 操作而讓效能大幅提昇。

Facebook 推出了 Hermes，為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine：「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy，針對行動裝置的特性而設計：避免 JIT 產生的 overhead，以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊：

不過沒有提到 CPU usage 會上升多少，只是帶過去：

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量，但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息，在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字，不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇，好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字，不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了，要一直壓榨效能，最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善)，現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料，而其他 workspace 的頁面就只保留狀態 (透過 Redux)：

從記憶體用量可以看出來：

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料，所以啟動時間也就下降了不少，但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render)，不過大概是考慮到常見情境下的切換次數而決定這樣做，應該還算 ok...

Vim 的 Performance Profiling

在「Profiling Vim」這邊看到 Vim 上常見的效能問題，很多時候會覺得「慢」但不知道慢在哪邊的問題...

文章作者已經知道是開 Markdown 檔案時的問題，所以可以在開啟 Vim 後用下指令啟動 profiling，但如果是想要追蹤一開起來很慢的問題，可以看「對 Vim 啟動過程做效能分析」這篇的方式，直接在啟動時加上 --startuptime vim.log 這樣的語法，把 log 寫到 vim.log 裡面。

Cloudflare 因為 Regular Expression 炸掉的問題

先前 Cloudflare 就有先說明七月二日的 outage 是因為 regular expression 造成的 (ReDoS)，不過昨天發的文章更完整了，導致爆炸的 regular expression 都給出來了：「Details of the Cloudflare outage on July 2, 2019」。

ReDoS 不算是新的問題，但卻是不太好避免的問題，因為需要有經驗的工程師 (中過獎的工程師) 才比較容易知道哪些 regular expression 是有問題的... 另外就是有花時間研究 regular expression 演算法的工程師也比較容易避開。

也因次，ReDoS 算是這十年來大家在還的債，各家 framework 都因為這個問題改寫了不少 regular expression。

這次的重點在這串式子導致了 ReDoS：

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

通常容易中獎的地方就是無限制字元與 * & + 連發的地方，後面這塊 )*.*(?:.*=.*))) 看起來就不太妙，果然在後面的分析也有提到：

The critical part is .*(?:.*=.*).

以前應該是在 Formal language 裡學到的，在課堂裡面其實會學到不少業界常用工具的基礎理論...

為線上環境而最佳化的 Ruby：Fullstaq Ruby

最近看到的「Fullstaq Ruby」，專為線上環境最佳化的 Ruby：

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch：

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的：「What causes Ruby memory bloat?」，這篇主要是在討論記憶體用量的問題，以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後，增加呼叫 malloc_trim(0); 以釋放記憶體，作者發現這樣可以省下了大量的記憶體空間：

然後作者預期效能應該會有影響 (畢竟多做了一些事情)，所以找了有在做 Rails benchmark 的人幫忙測試，結果發現反而變快了：

這樣看起來有可能官方會考慮把這個 patch 直接包進去？不過這看起來是在使用 jemalloc 的前提下？不知道如果使用標準的 glibc 會怎麼樣...

Raspberry Pi 4 開賣，USD$35

Raspberry Pi 4 開賣，目前推出的是 Model B，最低規格的 1GB RAM 版本與之前 RPi 3 相同都是 USD$35，另外這次提供了以前沒有的 2GB 與 4GB 版本，分別是 USD$45 與 USD$55：「Raspberry Pi 4 on sale now from $35」。

有兩個比較大而且要注意的改變，第一個是電源接頭變成 Type-C 了：

We’ve moved from USB micro-B to USB-C for our power connector. This supports an extra 500mA of current, ensuring we have a full 1.2A for downstream USB devices, even under heavy CPU load.

另外一個是 HDMI 接頭換成 D Type：

To accommodate dual display output within the existing board footprint, we’ve replaced the type-A (full-size) HDMI connector with a pair of type-D (micro) HDMI connectors.

這兩個改變都需要準備額外的設備或是線材，其他的改變應該還好...

這次改版最明顯的是效能的增加，官方宣稱 CPU 速度是前一代的三倍：

A 1.5GHz quad-core 64-bit ARM Cortex-A72 CPU (~3× performance)

而在 GPU 相關的則是對 H.265 的 4Kp60 硬體解壓縮：

4Kp60 hardware decode of HEVC video

先前用 RPi 3 放客廳還是覺得不太夠，也許可以考慮看看這個...

Microsoft 釋出一個效能極佳的 Malloc Library

在 Hacker News 上看到的：「Mimalloc – A compact general purpose allocator with excellent performance (github.com)」，專案網站在 GitHub 上：「mimalloc is a compact general purpose allocator with excellent performance.」。

現代伺服器軟體比較常用的應該是 jemalloc，許多軟體也直接把 jemalloc 包進去 (像是 Firefox)，所以各種測試主要就是看與 jemalloc 的差異。

測試的機器有點怪，既然都是在 AWS 上測試，卻不是選目前主流的 Intel，而且就算是 AMD 也不是選最大台的 r5a.24xlarge (都是在去年 2018 年十一月發表的)：

Testing on a big Amazon EC2 instance (r5a.4xlarge) consisting of a 16-core AMD EPYC 7000 at 2.5GHz with 128GB ECC memory, runningUbuntu 18.04.1 with LibC 2.27 and GCC 7.3.0.

尋著留言有看到 daanx/mimalloc-bench 這邊有使用 Intel 平台的測試，也有類似的結果，所以應該是還 ok...

Anyway，依據目前官方給的的效能測試，看起來頗不賴：

而且實際的記憶體用量也比以前少，這邊在看資料時官方有附註，有些測試在這邊因為執行方式所以不會準：

(note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs).

至於實際上是不是真的在 general purpose 都可以提昇效能，應該會等著比較大的社群玩看看... 尤其是 Percona 對只要換個 library 就能提昇效能的東西，他們基本上都不會放棄嘗試...