Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題,在 BBRv2 有一些改善 (目前還在測試階段,在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明),而 Dropbox 則是跳下去測試,並且公佈結果:「Evaluating BBRv2 on the Dropbox Edge Network」。


Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢,但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到:我自己的 Ubuntu 桌機跑 BBRv1,在我上傳大量資料的時候 (只開一條連線),會導致 PPPoE 的 health check 失敗,於是就斷線了,另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE,也可以看到斷線嘗試重連的訊息,於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高,除了我遇到的問題外,這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平):

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制,可以更清楚知道塞住的情況。

整體上來說應該會好不少,不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1,或是不換,讓 BBRv1 與 BBRv2 共存?

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.

省頻寬的方法:終極版本...

看到「Three ways to reduce the costs of your HTTP(S) API on AWS」這邊介紹在 AWS 上省頻寬費用的方法,看了只能一直笑 XD

第一個是降低 HTTP response 裡沒有用到的 header,因為每天有五十億個 HTTP request,所以只要省 1byte 就是省下 USD$0.25/day:

Since we would send this five billion times per day, every byte we could shave off would save five gigabytes of outgoing data, for a saving of 25 cents per day per byte removed.

然後調了一些參數後省下 USD$1,500/month:

Sending 109 bytes instead of 333 means saving $56 per day, or a bit over $1,500 per month.

第二個是想辦法在 TLS 這邊下手,一開始其中一個方向是利用 TLS session resumption 降低第二次連線的成本,但他們發現沒有什麼參數可以調整:

One thing that reduces handshake transfer size is TLS session resumption. Basically, when a client connects to the service for the second time, it can ask the server to resume the previous TLS session instead of starting a new one, meaning that it doesn’t have to send the certificate again. By looking at access logs, we found that 11% of requests were using a reused TLS session. However, we have a very diverse set of clients that we don’t have much control over, and we also couldn’t find any settings for the AWS Application Load Balancer for session cache size or similar, so there isn’t really anything we can do to affect this.

所以改成把 idle 時間拉長 (避免重新連線):

That leaves reducing the number of handshakes required by reducing the number of connections that the clients need to establish. The default setting for AWS load balancers is to close idle connections after 60 seconds, but it seems to be beneficial to raise this to 10 minutes. This reduced data transfer costs by an additional 8%.

再來是 AWS 本身發的 SSL certification 太肥,所以他們換成 DigiCert 發的,大幅降低憑證本身的大小,反而省下 USD$200/day:

So given that the clients establish approximately two billion connections per day, we’d expect to save four terabytes of outgoing data every day. The actual savings were closer to three terabytes, but this still reduced data transfer costs for a typical day by almost $200.

這些方法真的是頗有趣的 XDDD

不過這些方法也是在想辦法壓榨降低與 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

把 PostgreSQL 的 EXPLAIN 轉成 Flamegraph

Hacker News Daily 上看到 mgartner/pg_flame 這個專案,可以把 PostgreSQLEXPLAIN 結果 (JSON 格式) 轉成 Flamegraph (用 HTML 呈現):

不過我是直接看 EXPLAIN 的輸出比較習慣... 但如果需要做投影片的時候,應該是個好工具?

換到 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 也快出了...

Google Chrome 要藉由拆開 HTTP Cache 提昇隱私

在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的,Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。

有 cache 跟沒有 cache 可以從讀取時間猜測出來,這樣就可以知道瀏覽器是否有這個特定 url 的 cache。

在原文的作者所給的例子沒有這麼明顯,這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章,我就拿這篇文章裡面特有的資源來判斷。

以這篇文章來說,我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間,藉此我就可以反推你有沒有看過這篇文章,達到攻擊隱私的效果。

解決的方法就是作者文章裡所提到的方法,把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能,而 Firefox 正在研究中)。

當然這樣做應該會對流量有些影響,但考慮到這些日子有很多新技術可以增加下載速度,這個功能應該是還能做...