Tag: performance

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

在「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 的評論

開頭我先說一下我的想法，我對於 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 的優先順序

前陣子看到「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

也是在「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 也會增加...

Internet 上的 3rd party js 的情況

在 Twitter 上看到這則：

裡面提到了「patrickhulce/third-party-web」的分析 (作者是從 HTTP Archive 的資料分析)，裡面依照不同種類的 3rd party js (像是 ad，或是 social element，或是分析工具) 需要執行的時間，以及使用的站台數量。

Social 那邊意外看到 PIXNET 有上去，然後速度只比 Disqus 快一些，應該是沒有 optimize 的關係。

如果整體一起看的話 (總和花費時間)，可以看到 Google 各項產品都在最前面，畢竟裡面每個項目都是被廣泛使用的。

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機：「Linode 推出 Dedicated CPU Instances」，現在找機會測試看看，拿了 Linode 的 Dedicated (4GB) 與 AWS 的 c5.large 比較，同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nench 與 OpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試，我把結果都貼到這邊：「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD，而 AWS 用的是 Intel，所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據，可以看到不同演算法的差異還蠻大的，馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的：

  • 在 cipher 類的測試我只測了 AES (目前的主流)，小的 block (16/64/256 bytes) 時 AMD 會輸一些，但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中，跑 MD5 時 Linode 則是輸一些，但 SHA1 反而是贏一些，然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA，則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半，應該是還不錯...

TiDB 單機效能

TiDB 是一個支援分散式運算的資料庫，希望能夠完整地模擬 MySQL Protocol，而 Percona 試著測試 TiDB 在單機的效能，雖然測試的項目很簡單，但結果頗有趣的：「A Quick Look into TiDB Performance on a Single Server」。

Percona 觀察到的現象是 TiDB 對於單一 SQL query 支援多 CPU 運算 (MySQL 只會使用單 CPU)，所以在高階的機器上，某些 SQL query 會快很多。而 OLAP 類型的 SQL query 也不錯，但常見的 OLTP 應用則慢不少：

Short version: TiDB supports parallel query execution for selects and can utilize many more CPU cores – MySQL is limited to a single CPU core for a single select query. For the higher-end hardware – ec2 instances in my case – TiDB can be 3-4 times faster for complex select queries (OLAP workload) which do not use, or benefit from, indexes. At the same time point selects and writes, especially inserts, can be 5x-10x slower. Again, please note that this test was on a single server, with a single TiKV process.

是個有趣的 drop-in...

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外，在「Preload Scripts」這邊看到的技巧，可以跟 browser 說明哪些資源比較重要，請儘快先下載：

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法，這個技巧應該用在會卡住頁面呈現的部分，確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面，理論上會更快：

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助，建議可以跑 A/B test 看看效果：

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法，算是常見的疑慮都列出來了：「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題：

  • 因為 UDP 導致 firewall 可能沒開，以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理，而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題，以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞，等於是在 UDP 上面又重做了一次 TCP congestion algorithm，而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮，之後如果有進展的話，可以再拿出來當 checklist 再確認有哪些有改善...

EC2 開始陸續推出支援 100Gbps 網路的機器

AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了：「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。

從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路，現在推出的 p3dn.24xlarge 是第二個支援的...

另外是 P3 系列的降價消息，比較奇怪的是從 2018/12/06 開始生效，而不是從月初開始。另外區域與條件也有一些複雜，有常在用的人可以翻一下說明...