Cloudflare 看 HTTP/3 的使用率

Cloudflare 利用自家平台分析過去一年 HTTP/3 的使用率:「Examining HTTP/3 usage one year on」。

首先是整體的使用率,看起來反而沒有什麼太大的變化?一上線就已經是巔峰的感覺?

然後各種 bot (像是搜尋引擎的 bot 或是 social media 的 bot) 看起來幾乎都沒有用 HTTP/3,少數的量應該都是實驗性質居多,唯一的例外是 LinkedIn 有試著在導入,可以看到慢慢的爬升:

看起來不算太順?

畫 Python 下記憶體使用情況的 Flamegraph:Memray

前幾天的 Hacker News Daily 上看到的東西,是由 Bloomberg 開發出來的工具 Memray,這個工具是一個 Python 套件:

Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself.

套件有多種輸出,其中一種是可以產生出記憶體使用情況的 flamegraph,轉成圖檔後像是這樣:

官方支援 Python 3.7+:

Memray requires Python 3.7+ and can be easily installed using most common Python packaging tools.

用法看起來也很簡單,之後如果有需要看 memory footprint 的情況好像可以拿來用看看...

現在的 Android 市場分佈情況

剛剛看 Let's Encrypt 的「Standing on Our Own Two Feet」這篇時才發現現在 Android 市場分佈情況需要從 Android Studio 上翻:

Google no longer provides version numbers on its Distribution Dashboard, but you can still get some data by downloading Android Studio.

一路往前對應的報導分別是「Android Version Distribution statistics will now only be available in Android Studio」以及「Google kills Android distribution numbers on the web, but we’ve got you covered」。

至少有資料可以翻... 這樣看起來如果以 1% 為界線的話得要支援到 4.2?如果放寬到 2% 的話也得 4.4。如果只支援 5.0+,表示放掉快 6% 的使用者?

如果是走東南亞的話應該會更痛苦了,明天去找人聊聊好了 @_@

AWS Cloud 的用法

Hacker News Daily 上看到這則,分享了 AWS (他的前東家,超過八年) 的使用經驗:

除了可以在 Twitter 上看以外,也可以用 Thread reader 直接讀整條 thread,應該也還算清楚:「This is how I use the good parts of @awscloud, while filtering out all the distracting hype.」。

這邊的經驗談主要是在 web 與 app 相關的服務這塊:

有講到 AWS 的業務其實圍繞在 scalability 上發展,但這對 startup 可能反而是扣分,因為暴力法解反而可以大幅簡化架構換得 agile (而讓 startup 存活下來)。

另外從團隊的開發成本來看,這些 scale 的技術增加了開發成本,產生了很多開發上的限制,這些觀點也有點帶到「Premature optimization is the root of all evil」在講的事情:

最後的結論可以看到一些列表:

除了 DynamoDB 的意見不同外 (這邊提到的 DDB),其他的我都可以接受...

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息,在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字,不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇,好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字,不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了,要一直壓榨效能,最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善),現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料,而其他 workspace 的頁面就只保留狀態 (透過 Redux):

從記憶體用量可以看出來:

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料,所以啟動時間也就下降了不少,但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render),不過大概是考慮到常見情境下的切換次數而決定這樣做,應該還算 ok...

為線上環境而最佳化的 Ruby:Fullstaq Ruby

最近看到的「Fullstaq Ruby」,專為線上環境最佳化的 Ruby

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch:

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的:「What causes Ruby memory bloat?」,這篇主要是在討論記憶體用量的問題,以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後,增加呼叫 malloc_trim(0); 以釋放記憶體,作者發現這樣可以省下了大量的記憶體空間:

然後作者預期效能應該會有影響 (畢竟多做了一些事情),所以找了有在做 Rails benchmark 的人幫忙測試,結果發現反而變快了:

這樣看起來有可能官方會考慮把這個 patch 直接包進去?不過這看起來是在使用 jemalloc 的前提下?不知道如果使用標準的 glibc 會怎麼樣...

Google Cloud Platform 的終身免費方案

Google 在這次 Google Cloud Next '17 公佈了 Google Cloud Platform Free TierAlways Free Usage Limits,也就是終身免費的方案。

這次宣佈的包括了許多服務。掃了一遍應該會去玩 GCE 的部份,包括了 0.6GB RAM 的機器以及 1GB 的對外流量 (不過到中國與澳洲要另外計費,不包含在這個範圍內)。

領先者的 AWS 不知道會不會也跟進...

HTML5 的 meter 元素...

Zite 上看到 HTML5 的 meter 元素:「The HTML5 meter Element」,這個元素的 spec 在「4.10.17 The meter element」。

用來表示比率的元素,像是 progress bar,或是使用率...

這是直接用你的瀏覽器 render <meter min="0" max="100" value="50"></meter> 的結果:

這是示意圖 (有點大 XD):

依照 caniuse.com 上的說明,比較新的桌面瀏覽器都支援了:「Progress & Meter」。

以往應該都是自己用 div 處理,現在看起來可以用這個元素,再用 JavaScript 對 IE 處理了?