Tag: speed

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論，無論是 HTTP/1.1 時代，或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push)，各種讓下載速度最佳化的技巧以及造成的複雜度：「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧，也就是 JavaScript 的 bundle，或是 CSS 的 Image sprites，甚至是 API 的合併，像是很多人會考慮的 GraphQL。

雖然在 HTTP/2 年代我們常說可以省下來，但這並不代表「打包」在 HTTP/2 情境下沒有效果，只是改善的幅度比較少，所以這個最佳化的技巧比起 HTTP/1.1 年代，可以放到後面一點再做，先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了)，其實繼續使用沒有太大問題...

另外是 Server Push 的情境，意外的反而可以提昇不少速度，看起來主要是少了請求的時間，所以快不少。

再來是跨網域時 CORS 的問題，在 Flash 的年代是一個 crossdomain.xml 解決，但現在的解法是多一個 OPTIONS request，反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制：「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的：

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

改善內嵌 YouTube 影片的載入速度

YouTube 的 embed 會載入大量的元件，所以就有專案把對使用者沒有意義的元件都拔掉：「Lite YouTube Embed」。

從比較可以看出來 Lite YouTube Embed 下載的元件少很多：

當然在功能上有差異，不過基本的功能應該都沒問題...

雖然還是 JavaScript 實做，但可以看到實際的程式碼大概 40 行而已？(註解的行數大約是程式碼的兩倍)：「lite-youtube-embed/src/lite-yt-embed.js」。

不過要注意的是，程式碼中用到 ES6 的 class 語法，所以如果要考慮到 IE11，應該是要打包轉換...

AWS Lambda 的 Provisioned Concurrency

AWS Lambda 推出了 Provisioned Concurrency，降低冷啟動所需要的時間以確保效率：「New – Provisioned Concurrency for Lambda Functions」。

看 benchmark 的資料就很清楚，可以避免冷啟動所產生的延遲：

這邊也可以看出來就算是冷啟動，大約也是多個一秒多。如果這個延遲是需要被處理的，就可以考慮用 Provisioned Concurrency 了。

價位上是依照保留的量：

You only pay for the amount of concurrency that you configure and for the period of time that you configure it. Pricing in US East (N. Virginia) is $0.015 per GB-hour for Provisioned Concurrency and $0.035 per GB-hour for Duration. The number of requests is charged at the same rate as normal functions. You can find more information in the Lambda pricing page.

不過如果量再更大，而且考慮成本，應該會考慮改回傳統的架構，用多台 EC2 instance 跑...

CloudFront 的 BBR 效能提昇

這是在找一些 TCP congestion algorithm 相關的資訊時發現的，看起來 Amazon CloudFront 導入 BBR 一陣子了：「TCP BBR Congestion Control with Amazon CloudFront」。

不過 BBR 被研究的愈來愈多，大家開始發現這個演算法的霸道，跟其他的 TCP congestion algorithm 並不太能和平共存，但這就跟軍事武器一樣，隔壁升級了你就得跟著升級，抱怨沒有用，只會被消滅...

Amazon Redshift 會自動在背景重新排序資料以增加效能

Amazon Redshift 的新功能，會自動在背景重新排序資料以增加效能：「Amazon Redshift introduces Automatic Table Sort, an automated alternative to Vacuum Sort」。

版本要到更新到 1.0.11118，然後預設就會打開：

This feature is available in Redshift 1.0.11118 and later.

Automatic table sort is now enabled by default on Redshift tables where a sort key is specified.

重新排序的運算會在背景處理，另外帶一些行為學習分析：

Redshift runs the sorting in the background and re-organizes the data in tables to maintain sort order and provide optimal performance. This operation does not interrupt query processing and reduces the compute resources required by operating only on frequently accessed blocks of data. It prioritizes which blocks of table to sort by analyzing query patterns using machine learning.

算是丟著讓他跑就好的東西，升級上去後可以看一下 CloudWatch 的報告，這邊沒有特別講應該是還好... XD

換到 PHP 7.3

上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」)，這次是在整理機器時發現 blog 這台機器還在跑 7.2，就更新一下系統把上面的站台都換到 7.3。

蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」)，目前看到的資料都會快一些，應該是沒有太大問題，之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB，但用 opcache-status 看起來只用了 65 MB 左右)，把記憶體空間讓給其他程式用...

不過 7.4 也快出了...

Linux 上 Intel CPU 的安全性修正與效能的影響

在 Hacker News Daily 上看到在講 Intel CPU 因為各種安全性問題，而需要在 Linux Kernel 上修正，所產生的效能問題：「HOWTO make Linux run blazing fast (again) on Intel CPUs」。

這一系列的子彈也飛得夠久了 (雖然還是一直有其他的小子彈在飛)，所以回過頭來看一下目前的情況。

這邊主要的測試是針對 mitigations=off 與 SMT 的啟用兩個項目在測 (SMT 在 Intel 上叫做 Hyper-threading)，可以看到這兩份測試結果，目前的 mitigation 對效能的影響其實已經逐漸降到可以接受的程度 (小於 5%)，但關閉 SMT 造成的效能影響大約都在 20%～30%：

但是開啟 SMT 基本上是個大坑，如果有關注大家在挖洞的對象，可以看到一堆 Intel CPU 上專屬的安全性問題都跟 SMT 有關...

剛好岔個題聊一下，先前弄了一顆 AMD 的 Ryzen 7 3700X 在用 (也是跑 Linux 桌機)，才感受到現在的網頁真的很吃 CPU，開個網頁版的 Slack 與 Office 365 的速度比原來的老機器快了好多，差點想要把家裡的桌機也換掉...

用更少訓練時間的 KataGo

最近開始在不同的地方會看到 KataGo 這個名字 (Twitter 與 YouTube 上都有看到)，翻了一下資料發現是在訓練成本上有重大突破，依照論文的宣稱快了五十倍...

在第一次跑的時候，只用了 35 張 V100 跑七天就有 Leela Zero 第 130 代的強度：

The first serious run of KataGo ran for 7 days in Februrary 2019 on up to 35xV100 GPUs. This is the run featured in the paper. It achieved close to LZ130 strength before it was halted, or up to just barely superhuman.

而第二次跑的時候用了 28 張 V100 跑 20 blocks 的訓練，跑了 19 天就已經超越 Facebook 當初提供的 ELFv2 版本，而對應到 Leela Zero 大約是第 200 代左右的強度 (要注意的是在 Leela Zero 這邊已經是用 40 blocks 的結構訓練了一陣子了)：

Following some further improvements and much-improved hyperparameters, KataGo performed a second serious run in May-June a max of 28xV100 GPUs, surpassing the February run after just three and a half days. The run was halted after 19 days, with the final 20-block networks reaching a final strength slightly stronger than LZ-ELFv2! (This is Facebook's very strong 20-block ELF network, running on Leela Zero's search architecture). Comparing to the yet larger Leela Zero 40-block networks, KataGo's network falls somewhere around LZ200 at visit parity, despite only itself being 20 blocks.

從論文裡面可以看到，跟 Leela Zero 一樣是逐步提昇 (應該也是用 Net2Net)，而不是一開始就拉到 20x256：

In KataGo’s main 19-day run, (b, c) began at (6, 96) and switched to (10, 128), (15, 192), and (20, 256), at roughly 0.75 days, 1.75 days, and 7.5 days, respectively. The final size approximately matches that of AlphaZero and ELF.

訓練速度上會有這麼大的改善，分成兩個類型，一種是一般性的 (在「Major General Improvements」這章)，另外一類是特定於圍棋領域的改進 (在「Major Domain-Specific Improvements」這章)。

在 Leela Zero 的 issue tracking 裡面也可以看到很多關於 KataGo 的消息，看起來作者也在裡面一起討論，應該會有一些結果出來...

延遲載入 CSS 的方式

在「Simpler way to load CSS asynchronously」這邊看到的技巧，利用了 onload 與 <noscript> 的方式，達成延遲載入 CSS 的效果：

<link rel="stylesheet" href="/path/to/my.css"
      media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

對於非必要的 CSS 可以用這樣的方式加強，看起來頗不賴... 這邊提到的方式，作者是引用「Smashing Newsletter: Issue #234」，不過查了一下發現 2015 的時候有人在 StackOverflow 上回答過：「How to load CSS Asynchronously」，不確定有沒有更早的資料...

另外一個比較新的語法是使用 rel="preload"，但支援度就不太好了，需要靠 polyfill 之類的方式補上 (於是又多了一些東西要 load)，反而不如前面提到的方式來的簡單。

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