Python 新的 HTTP client library:HTTPX

看到「A next-generation HTTP client for Python.」這個專案冒出來,宣稱是下一代 Python 的 HTTP client library:

HTTPX is a fully featured HTTP client for Python 3, which provides sync and async APIs, and support for both HTTP/1.1 and HTTP/2.

目前專案還在 beta,目標是在今年四月出 1.0 版。從說明裡面可以看到,目前的方向是打算相容 requests,讓現有的程式可以不用做太多修改就轉移過來。

再來從開發者的角度來看,HTTPX 比 requests 多了這些功能:

  • Standard synchronous interface, but with async support if you need it.
  • HTTP/1.1 and HTTP/2 support.
  • Ability to make requests directly to WSGI applications or ASGI applications.
  • Strict timeouts everywhere.

但如果就支援這些功能的角度來看,修改 requests 看起來應該會比較快?開新的專案感覺跟 Kenneth Reitz 有關...

Kenneth Reitz 有兩個很有名的作品,一個是這個,另外一個是 Pipenv,也就是在「pipenv 的凋零與替代方案 poetry」這邊提到的事情。

然後看了一下 CHANGELOG.md 內的資訊,裡面最早的記錄是 0.6.0 (2019/06/21),而從 Contributors to encode/httpx 這頁看起來則是 2019/03/31 開始發展的,就這些時間點看起來,原因大概跟 Kenneth Reitz 有關... 雖然沒有找到文章直接提到這件事情。

不過 HTTPX 需要 Python 3.6+ 才能跑,對於版本的要求比較高,如果是 16.04 預設的 python3 (3.5) 就沒辦法跑了,18.04 預設的 python3 (3.6) 也才剛好符合...

之後應該是 HTTPX 與 requests 兩邊都得關注了,看看會有什麼發展...

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 共存?

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

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

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

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

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

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

PostgreSQL 上去識別化的套件

在「PostgreSQL Anonymizer 0.5: Generalization and k-anonymity」這邊看到的套件,看起來可以做到一些常見而且簡單的去識別化功能:

The extension supports 3 different anonymization strategies: Dynamic Masking, In-Place Anonymization and Anonymous Dumps. It also offers a large choice of Masking Functions: Substitution, Randomization, Faking, Partial Scrambling, Shuffling, Noise Addition and Generalization.

看起來可以把欄位轉成 range 這件事情半自動化處理掉 (還是需要 SQL 本身呼叫這些函數),之後遇到 PII 的時候也許會用到...

擋 Live 與 Podcast 內廣告的工具

看到「An adblocker for live radio streams and podcasts. Machine learning meets Shazam.」這個專案,這個把 machine learning 用到「正途」上了啊...

不過畢竟是比較複雜的演算法,會吃不少 CPU 資源:

On a regular laptop CPU and with the Python time-frequency analyser, computations run at 5-10X for files and at 10-20% usage for live stream.

不過看用法還是偏向 library 性質,如果要大力推廣可能還是需要有其他人包個更好的界面...

即時將動畫 Upscale 到 4K 畫質的演算法

看到「Anime4K」這個專案:

Anime4K is a state-of-the-art*, open-source, high-quality real-time anime upscaling algorithm that can be implemented in any programming language.

State of the art* as of August 2019 in the real time anime upscaling category, the fastest at acheiving reasonable quality. We do not claim this is a superior quality general purpose SISR algorithm compared to machine learning approaches.

他們提供的數據顯示 1080p -> 2160p (4K) 只要 3ms,對於 60fps 來說是相當足夠,而品質看起來也還不錯。

其中一個蠻有趣的問答是 1080p -> 2160p 反而比 480p -> 720p 簡單,因為 1080p 裡面因為有更多資料量,所以處理起來比較簡單:

Why not do PSNR/SSIM on 480p->720p upscaling
Story Time

Comparing PSNR/SSIM on 480p->720p upscales does not prove and is not a good indicator of 1080p->2160p upscaling quality. (Eg. poor performance of waifu2x on 1080p anime) 480p anime images have a lot of high frequency information (lines might be thinner than 1 pixel), while 1080p anime images have a lot of redundant information. 1080p->2160p upscaling on anime is thus objectively easier than 480p->720p.

robots.txt 的標準化

雖然聽起來有點詭異,但 robots.txt 的確一直都只是業界慣用標準,而非正式標準,所以各家搜尋引擎加加減減都有一些自己的參數。

在經過這麼久以後,Google 決定推動 robots.txt 的標準化:「Formalizing the Robots Exclusion Protocol Specification」,同時 Google 也放出了他們解讀 robots.txt 的 parser:「Google's robots.txt Parser is Now Open Source」,在 GitHubgoogle/robotstxt 這邊可以取得。

目前的 draft 是 00 版,可以在 draft-rep-wg-topic-00 這邊看到,不知道其他搜尋引擎會給什麼樣的回饋...

Microsoft 釋出一個效能極佳的 Malloc Library

Hacker News 上看到的:「Mimalloc – A compact general purpose allocator with excellent performance (github.com)」,專案網站在 GitHub 上:「mimalloc is a compact general purpose allocator with excellent performance.」。

現代伺服器軟體比較常用的應該是 jemalloc,許多軟體也直接把 jemalloc 包進去 (像是 Firefox),所以各種測試主要就是看與 jemalloc 的差異。

測試的機器有點怪,既然都是在 AWS 上測試,卻不是選目前主流的 Intel,而且就算是 AMD 也不是選最大台的 r5a.24xlarge (都是在去年 2018 年十一月發表的):

Testing on a big Amazon EC2 instance (r5a.4xlarge) consisting of a 16-core AMD EPYC 7000 at 2.5GHz with 128GB ECC memory, runningUbuntu 18.04.1 with LibC 2.27 and GCC 7.3.0.

尋著留言有看到 daanx/mimalloc-bench 這邊有使用 Intel 平台的測試,也有類似的結果,所以應該是還 ok...

Anyway,依據目前官方給的的效能測試,看起來頗不賴:

而且實際的記憶體用量也比以前少,這邊在看資料時官方有附註,有些測試在這邊因為執行方式所以不會準:

(note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs).

至於實際上是不是真的在 general purpose 都可以提昇效能,應該會等著比較大的社群玩看看... 尤其是 Percona 對只要換個 library 就能提昇效能的東西,他們基本上都不會放棄嘗試...

Salesforce 弄了一個新的玩意出來...

然後在 Hacker News 上被酸爆了:「Open-sourcing the Lightning Web Components framework (salesforce.com)」。引用的原文在「Introducing Lightning Web Components Open Source」這邊。

主要還是大家已經厭倦前端一直丟東西出來,但是速度一直都沒什麼改善... 用傳統的 server rendering 反而省了不少 client 端的 CPU resource。

話說回來,前幾天的伺服器爆炸好像沒看到什麼後續新聞... (參考「Salesforce enables modify all in all user profiles」、「Salesforce系統更新意外造成權限擴張,用戶服務被迫中斷」)。