Tag Archives: performance

在一連串的安全更新後，AMD 的 CPU 比 Intel 快了...

Leave a reply

在「Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches」這邊看到的測試：

把現有的安全性更新都開啟後，Intel CPU 的效能掉了 20% 左右 (在 Intel 上需要把 HT 關掉)：

While the impacts vary tremendously from virtually nothing too significant on an application-by-application level, the collective whack is ~15-16 percent on all Intel CPUs without Hyper-Threading disabled. Disabling increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K).

The AMD CPUs are not tested with HT disabled, because disabling SMT isn’t a required fix for the situation on AMD chips, but the cumulative impact of the decline is much smaller. AMD loses ~3 percent with all fixes enabled

可以注意到兩家目前桌機的頂規在上了安全性更新後，AMD 的 2990WX 比 Intel 的 7980XE 快了一些些... 當初擠牙膏擠出來的都吐回去了，不知道之後出的 security issue 還需要再吐多少回去。

把 Blog 上的 PNG 圖片換成 WebP 格式

4 Replies

WebP 格式的大小比起 JPEG 或是 PNG 都小不少，支援度也都還行，但 Safari 不支援是個大問題，因為在行動裝置裡面 iOS 還是大宗...

目前想到的方法是只對 Imgur 的圖片使用 WebP (.webp)，當遇到不支援的 WebP 的平台時透過 JavaScript 改用 PNG (.png)。

這邊有判斷有沒有支援 WebP 的程式碼出自「Detect WEBP Support with JavaScript」，用 createImageBitmap() 建看看有沒有成功：

(() => {
  let supportsWebP = async () => {
    if (!self.createImageBitmap) return false;
    const webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
    const blob = await fetch(webpData).then(r => r.blob());
    return createImageBitmap(blob).then(() => true, () => false);
  };

  (async () => {
    if (!await supportsWebP()) {
      document.addEventListener('DOMContentLoaded', () => {
        for (let el of document.getElementsByTagName('img')) {
          let src = el.getAttribute('src');
          if (src.match(/\.webp/)) {
            el.setAttribute('src', src.replace(/\.webp/, '.png'));
          }
        }
      });
    }
  })();
})();

這邊比較有趣的是網路上的文件 (MDN 與 CanIuse) 都說 Safari 不支援 createImageBitmap()，但實際上好像沒問題 :o

然後再用 WordPress 的延伸套件「Search Regex」把所有文章理出現 /https:\/\/i\.imgur\.com/(\w+)\.png/ 的字串換成 https://i.imgur.com/$1.webp，接下來就可以拿 Safari 測試了，這樣有點 hack 但看起來還行...

加快 ls 的速度

Leave a reply

看到「When setting an environment variable gives you a 40x speedup」這篇在講 ls 的速度。

文章是由 Stanford 的 Sherlock 發出來的，不過看起來跟電視劇沒關係，從網站上的標語「The HPC cluster for all your computing needs」可以看出是 HPC 相關的單位。

在 HPC 環境裡面可以預期單一目錄裡會有很多檔案，所以使用者跑來抱怨 ls 的速度就不算太意外了。不過這次使用者有提到在他自己的 laptop 上跑 ls 反而很快：

It all started from a support question, from a user reporting a usability problem with ls taking several minutes to list the contents of a 15,000+ entries directory on $SCRATCH.

Having thousands of files in a single directory is usually not very file system-friendly, and definitely not recommended. The user knew this already and admitted that wasn’t great, but when he mentioned his laptop was 1,000x faster than Sherlock to list this directory’s contents, of course, it stung. So we looked deeper.

直接跳到後面的結論... 原因是出自於因為需要顯示不同顏色，而需要透過 lstat() 查詢額外的檔案性質 (可執行、setuid 以及 setgid 這些資料)，導致速度變慢：

From 13s with the default settings, to 0.3s with a small LS_COLORS tweak, that’s a 40x speedup right there, for the cheap price of not having setuid/setgid or executable files colorized differently.

Of course, this is now setup on Sherlock, for every user’s benefit.

透過設定 LS_COLORS='ex=00:su=00:sg=00:ca=00:'，可以讓 lstat() 消失，所以被放進 Sherlock 的預設值了... 而沒有遇到這個問題的環境 (像是有設計好對應的目錄結構)，或是想要維持原來的樣子的人，則可以 unset 掉這個值讓輸出還是有色彩差異 :o

針對 JavaScript 時代調整網頁的效能評估指標

Leave a reply

早期網頁的效能評估指標都沒有考慮 JavaScript 的情況，大多都是 TTFB (Time to First Byte) 或是網頁大小以及 DOMContentLoaded 或是 load 這類 DOM event 為主，但因為 Goodhart's law，現代的網頁設計會故意將許多 JavaScript 要做的事情搬到 load 以後開始做，以降低 load 被延遲的問題，讓前端的「KPI」比較好看：

When a measure becomes a target, it ceases to be a good measure.

但在 load 之後整個網站還是不能用，使用者的體驗其實很差，這個評估方式的價值變低不少。所以「Measuring Jank and UX」這篇就再找出一些新的指標，來評估 JavaScript 造成的問題。

可以看到文章裡面評估了很多關於 CPU loading 與操作時間的指標，也許這一兩年還會有用，不過我覺得還是會遇到 Goodhart's law 描述的問題... XD

Mac 上讓 SSH 走 Socks5 的方式

4 Replies

在泰國住的飯店提供頗快的網路：

不過到 HiNet 看起來應該是有繞到美國之類的地區？

gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report 168.95.1.1
Start: 2019-04-07T08:16:33+0700
HOST: Gea-Suans-MacBook-Pro.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                 0.0%    10    1.8   2.0   1.3   3.1   0.6
  2.|-- node-iyp.pool-101-108.dyn  0.0%    10    3.9   3.6   2.7   4.5   0.6
  3.|-- 172.17.36.105              0.0%    10    3.2   4.1   3.2   8.3   1.5
  4.|-- 203.113.44.205             0.0%    10    6.5   5.3   3.9   6.7   1.0
  5.|-- 203.113.44.177             0.0%    10    5.4   4.8   4.0   7.2   1.0
  6.|-- 203.113.37.194             0.0%    10    4.6   6.5   3.0  11.1   2.5
  7.|-- in-addr.net                0.0%    10    3.9   4.4   3.1   5.6   0.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- pcpd-4001.hinet.net        0.0%    10  355.4 356.9 355.1 365.4   3.0
 10.|-- pcpd-3212.hinet.net        0.0%    10  215.6 216.6 214.2 225.4   3.4
 11.|-- tpdt-3022.hinet.net        0.0%    10  219.4 215.9 214.0 221.5   2.5
 12.|-- tpdt-3012.hinet.net        0.0%    10  218.9 217.2 215.0 218.9   1.4
 13.|-- tpdb-3311.hinet.net        0.0%    10  212.5 212.9 211.9 214.1   0.6
 14.|-- 210-59-204-229.hinet-ip.h  0.0%    10  213.5 212.7 212.0 213.7   0.6
 15.|-- dns.hinet.net              0.0%    10  214.4 214.5 213.7 216.0   0.7

這樣有些影音服務只吃台灣 IP 就沒辦法用了，所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet，所以就得找 Mac 上 SSH 要怎麼設定 Socks5。

本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect())，但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理，因為 nc 有支援 Socks5。

所以就變成兩包 ssh 指令：

ssh -D 1081 gcp.server
ssh -D 1080 -o "ProxyCommand nc -X 5 -x 127.0.0.1:1081 %h %p" hinet.server

然後 127.0.0.1:1080 就是打通的版本了，可以讓瀏覽器直接掛上去使用。

至於後來想起來不需要用 Socks5，可以用 ssh -L 而笑出來又是另外一件事情了 :o

Cloudflare 自己用 Rust 寫了一套相容 WireGuard 協定的軟體

Leave a reply

Cloudflare 發現目前符合他們條件的 WireGuard 軟體效能不夠好，所以就用 Rust 寫了一套出來：「BoringTun, a userspace WireGuard implementation in Rust」，軟體在「BoringTun」這邊可以看到。

Cloudflare 的條件是 userspace 以及多平台，市面上有 wireguard-go 符合這兩個條件，但效能不太好，所以就下去寫了。

GitHub 的頁面上可以看出還在剛開始的階段，很多頁面都還只有個雛型... 等這幾天陸陸續續更新後再回來看好了。

儘量不使用 JavaScript 的前端設計...

1 Reply

在「A JavaScript-Free Frontend」這邊看到的，目前看起來還是很辛苦啊...

首先是可以看到他對 Asana 的抱怨：

First, I live in a rural area with only 2 Mbit/s down Internet connection. With a warm cache it takes 14 seconds for the Asana UI to become usable. Second, you can see below that the app is comprised of over 10MB of uncompressed JavaScript. That is a huge amount of code to execute. How is this acceptable?

現在前端頁面的 JavaScript 愈來愈大，除了下載時間之外，其實最卡的應該還是瀏覽器要處理編譯的時間。作者試著用現有的元素開發他的產品 Slimvoice，然後把心得整理出來... 其實還蠻考驗對 CSS 的基本功，有些東西是你根本不知道存在，另外有些東西是支援度的問題。

這個概念應該就是十多年前倡導的 Unobtrusive JavaScript，不過在這幾年前端框架雨後春筍般冒出來後就不太有人在管了 (一堆站台關掉 js 就不會動)，而這也大幅「促進」了瀏覽器對 js 執行速度的改善...

Percona 對於 PostgreSQL 使用 HugePages 的評論

Leave a reply

開頭我先說一下我的想法，我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋：

Hi,

A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇，也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響，同樣馬上又看到奇怪的東西...

首先是標示與圖片不合：

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB)，當做是標錯就好。

但這樣又跑出一個奇怪的結果，48GB 的資料量比較小，TPS 大約是 35K/33K/41K，但 112GB 資料量比較大，卻可以達到 39K/43K/41K~42K，反而比較快？我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch，先不管)，其中 pgbench 跑了 10 mins 與 60 mins 的版本，但是 sysbench 只跑了 10 mins 的版本？這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients)，如果以直覺來說的話，我反而還是會打開 HugePages (yeah 純粹是直覺)，我現在比較想知道他會在 Percona 裡面待多久...

Chrome 對各種 JavaScript 的優先順序

Leave a reply

前陣子看到「JavaScript Loading Priorities in Chrome」這篇，在分析 Google Chrome 對各種 JavaScript 的優先順序。

優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」，另外文章裡也有整理建議「Where should this be used?」。

看起來 <script defer> at the end of <body> 是全部裡面最低的，建議是給 Load "Related articles" 或是 "Give feedback" 這類功能，不過應該沒什麼人真的這樣用...

然後要注意的是，這邊分析的對象是 Google Chrome，實際在設計時應該要先考慮一般性的定義，再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

單機 10 萬個連線 MySQL

Leave a reply

也是在「Links: February 2019」這邊看到的，裡面提到了 Percona 的「MySQL Challenge: 100k Connections」。

Percona 的測試是希望每個連線都有在做事，而不是 idle connection，這個測試有點像是卡住時的情況？看起來只有這幾個參數比較特別：

table_open_cache = 200000
back_log=3500
max_connections=110000
max_prepared_stmt_count=1000000

max_connections 開多一點算是廢話，然後因為要做事所以 max_prepared_stmt_count 也多一些，back_log 可以讓 kernel 保留來不及處理的 TCP 連線。

看起來用 sysbench 測試還撐的住，跟理論差不多，隨著連線數的增加 latency 也會增加...