Tag: performance

AMD Ryzen Threadripper 3990X 在 Windows 上的效能

John Carmack 注意到在 AMD Ryzen Threadripper 3990X 上因為 Windows 的 group limit 限制而造成效能問題：

但這點可以透過打散到兩個 group 改善 (workaround) 而提昇速度：

然後順便看了一下目前 CPU Benchmark 網站上對於高階 CPU 的跑分數據「PassMark - CPU Mark High End CPUs)」，可以看到 AMD 最近真是香噴噴的，用 3950X (16C/32T，105W) 殺 Intel 目前最高分的 W-3275M (28C/56T，205W)，然後那個價差：

Intel 的 14nm 牙膏繼續擠...

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係，可以預期網路的流量一定會大幅提昇，但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化：「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比，可以看到許多區域的流量都有大幅成長，尤其是重災區的義大利與英國，不過這邊沒有給與 2019 三月的比較 (YoY)：

另外是這些流量成長的種類，可以看到 streaming、數位媒體與教育類的流量大幅成長：

在網路速度的部份，可以看到大多數的地區是下降的，但加州沒什麼影響，而日本反而是上升的，應該可以解讀為這兩個地區平常就有夠多的容量，所以真的有爆量而用到的時候反而不會是瓶頸？

接下來幾個月應該會更嚴峻...

Cloudflare 的另外一個策略：不熱門的資料只放到記憶體內

前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...

Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...

幫 2011 年的 Mac Mini 換 SSD

這台 Mac Mini 是我第一個蘋果產品 (退伍後在 PIXNET 的時候買的)，當時本來想在上面寫些東西，不過後來就一直當個終端機在用而已，到這幾年他的定位就是放在客廳當個播放器 (像是開 Twitch 或是 YouTube 在看)。

不過每次用都覺得開 Google Chrome 開的很慢，就興起將硬碟換成 SSD 硬碟的念頭了。至於記憶體，當初在買 Mac Mini 的時候應該是已經升級過，裡面是兩條 4GB 了，網路上是有人提到可以支援兩條 8GB，不過以目前客廳的用法，應該是用不到...

先對價錢做了一些功課，如果是自己處理，打算換成美光的 Crucial MX500，在 24h 是賣 $2,099 (不過後來是剛好有去光華一趟，就在光華買回來)，然後打電話問一下有提供更換服務的店家，500GB SSD 是 $3,500 換到好，1TB SSD 則是 $6,000。

以 500GB 的價錢倒是沒有到不能接受，但也不是能馬上就說 ok 的價位，還是得看一下有多麻煩才能決定要怎麼做。

所以就跑去看了一下 YouTube 上換 SSD 的影片，看起來只要有對應的螺絲起子，應該是可以自己換完。而我之前就有準備六角螺絲起子，應該是可以換下來：

實際拆的時候才發現，不只需要正六角的螺絲起子 (H 系列)，還需要星狀的螺絲起子 (T 系列)，本來想在 24h 下單隔天再來弄，突然想到這種東西在水電五金行應該有，當時才晚上八點，就跑去外面找了一組 (價錢也比 24h 便宜)，回來繼續拆...

有了正確的工具，拆開就簡單不少，反倒是裝回去折騰一陣子... 在裝有 WiFi 天線的那塊板子的四顆螺絲時卡了一個小時 (一直都只鎖的上去三顆)，最後本來是打算少鎖一顆螺絲，結果在準備放棄的時候突然暴力法把四個孔位都卡進去了，就順利把四顆螺絲都鎖上去...

接下來就是先開機進入 macOS Recovery 確認硬碟有被抓到，確認有被抓到以後，就可以準備重裝系統，這時候我拿 MBPR 下載 10.13 (High Sierra，這台 Mac Mini 能支援的最新版)，生出 USB 隨身碟裝機，然後插回 Mac Mini 重開機就可以裝系統了：

裝完後的開機速度很明顯快不少，裝軟體的速度也是，另外再打開一些網站看一看，冷啟動的速度都改善很多。

算是趁連假的時候整理一下硬體，還蠻有趣的...

在網路流量很大時，Container 的網路對資料庫效能的影響

在 Percona 的「How Container Networking Affects Database Performance」這篇在討論 Kubernetes 上選擇不同的 CNI 對於資料庫效能的影響。

最重要的是結果的這張圖：

可以看到 TPS 與 throughput 都有影響到，要注意的是這是兩個不同的工具測出來的結果，在 TPS 上是用 sysbench，可以看到最好的 Kube-Router 上也掉了 13% 的 TPS：

Another key thing we found was that even in the best-case with Kube-Router we see an approximate 13% decrease in database performance comparing bare metal to running within Kubernetes. This illustrates that there are still improvements to be made to the performance of container networking in Kubernetes.

throughput 是用 iperf3，只要不是真的掉很多，就沒那麼關心了...

不過這個測試另外一個解讀是，如果你用資料庫不單純是 PK find() 類的處理，那麼效能應該是還好，因為會有不少 CPU 資源 (以及對應的時間) 是用在 join 或是其他處理上，對於 latency 與 throughput 應該就沒有那麼敏感了...

sysbench 的 RNG

在 Percona 的 blog 上看到了 sysbench 的 RNG (Random Number Generator) 跟想像中的不太一樣：「What You May Not Know About Random Number Generation in Sysbench」。

預設是 Special：

而不是直覺的 Uniform (也有提供)：

另外還提供三種：

翻了翻可以翻到其他四個的理論基礎，但就是不知道 Special 的設計理論在哪裡...

AWS Global Accelerator 的 TCP 協定

AWS Global Accelerator 是讓使用者先連到最近的 AWS 節點，再透過 AWS 的骨幹網路連到服務上 (可以參考之前寫的「AWS 推出 Global Accelerator，用 AWS 的網路加速」這篇)，當時就有說支援 TCP 與 UDP，但剛剛看到「AWS Global Accelerator launches TCP Termination at the Edge」這篇的時候才注意到，本來的產品是把 TCP 封包當作 UDP 在處理，也就是 TCP 3-way handshake 還是要到服務節點本身處理。

現在這個 TCP Termination 的功能則是先在最近的節點上建立 TCP 連線，然後同時往後端的建立連線接起來：

Typically, a TCP connection is established by using a three-way handshake (that is, three messages) between the client on the internet and the application endpoint in the AWS Region. So the farther away the client is from the endpoint, the longer the initial connection setup takes. With TCP termination at the edge, Global Accelerator reduces initial setup time by establishing a TCP connection between the client and the AWS edge location closest to the client. At nearly the same time, Global Accelerator creates a second TCP connection between the edge location and the application endpoint in the AWS Region. With this process, the client gets a faster response from the Global Accelerator edge location, and the connection from the edge location to the application endpoint in the Region is optimized to run over the AWS global network.

這樣連線的速度就會更快，但有可能會有前面建起來但後面建不起來的情況需要處理，一般的應用程式應該還好，畢竟地球上有個 GFW 也常幹這種事情...

Google Fonts 的加速方式

這邊講的是透過 css (以及 js) 使用的 Google Fonts，作者想要改善這塊，加速網頁的速度：「Should you self-host Google Fonts?」。

作者第一個提到的技巧是個懶人技巧，只要加上 preconnect 預先把 HTTPS 連線建好，就可以提昇不少速度。因為這可以降低先取得 css 後才建立連線的速度差異：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

作者有提到 Google 在 css 檔案的
header 裡面本來就有加上 preconnect，但從前後比較可以看出，整個網頁的結束時間差了一秒 (這是作者在 Google Chrome 的 3G Slow 設定下模擬的)：

另外一個技巧是增加 swap，讓 Google Fonts 還沒有讀進來之前先用系統有的字型呈現。這樣不會出現整頁只有圖，然後突然字都冒出來的情況，也就是把一般在用的：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

加上 &display=swap：

<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

最後一招就是把字型放在自己家，差異就更大了：

另外一個好處是改善 privacy，不過好像沒特別提到...

JavaScript 的壓縮器 esbuild

esbuild 是個 JavaScript bundler & minifier，在 GitHub 上的副標提到了重點在於速度：

An extremely fast JavaScript bundler and minifier

從壓縮時間可以看出來優勢：

另外從最終的檔案大小也可以看出來，與最小的 rollup + terser 組合沒有差太多：

實際拿個 jQuery 跑看看，可以看出來壓縮的效果還行：

-rw-r--r-- 1 gslin staff  89228 Feb 19 06:03 jquery-3.4.1-esbuild.min.js
-rw-r--r-- 1 gslin staff 280364 May  2  2019 jquery-3.4.1.js
-rw-r--r-- 1 gslin staff  88145 May  2  2019 jquery-3.4.1.min.js

速度主要是透過 Golang 並且平行化運算達到的：

  • It's written in Go, a language that compiles to native code
  • Parsing, printing, and source map generation are all fully parallelized
  • Everything is done in very few passes without expensive data transformations
  • Code is written with speed in mind, and tries to avoid unnecessary allocations

不過作者有提到這個專案畢竟比較新，還沒有被時間磨練過，可能會有些 bug：

This is a hobby project that I wrote over the 2019-2020 winter break. I believe that it's relatively complete and functional. However, it's brand new code and probably has a lot of bugs. It also hasn't yet been used in production by anyone. Use at your own risk.

可以先放一陣子看看，讓一些先賢先烈把比較大的 bug 踩一踩修一修...

Runtime 期間的最佳化工具：Dynimize

忘記在哪邊看到「Reduce MySQL CPU Usage Through Dynamic Binary Optimization」這篇文章了，裡面其實是在描述自家產品 Dynimize 的威猛。

翻了一些資料可以發現這個產品出來一陣子了，在 2018 的時候曾經在 Percona Live 上發表過：「Accelerating MySQL with JIT Compilers」，可以看出來有點像是 PGO (Profile-guided optimization) 的行為，只是他可以直接對 binary 處理。

定價的部份會是這類產品的重點，如果價錢比加硬體貴的話就沒那麼好用了... 在 Dynimize Pricing 這邊可以看到是 per CPU 的價錢，$0.00139/hr、$1/month 或是一次性的 $24，以效能提昇的程度來看，如果在 database 這邊是 CPU bound，是個頗值得投資的項目。