Google 再次改善 Android 的 APK 更新,讓下載的量更小

Google 的人再次更新了演算法,將下載的量再次減少,從本來的 47% 降到 65%:「Saving Data: Reducing the size of App Updates by 65%」。

今年七月的時候,更新演算法導入了 bsdiff,使得本來要抓整包 APK 的量,變成抓 diff 的部份,這使得下載的流量降了 47%:「Improvements for smaller app downloads on Google Play」。

Using bsdiff, we were able to reduce the size of app updates on average by 47% compared to the full APK size.

現在則改成不直接對 APK 做 diff,而是對未壓縮的檔案做,再把差異包起來,則可以降到 65%:

Today, we're excited to share a new approach that goes further — File-by-File patching. App Updates using File-by-File patching are, on average, 65% smaller than the full app, and in some cases more than 90% smaller.

主要的原因在於 APK 的壓縮使用的 DEFLATE 演算法對於變更非常敏感,改變一個字元就會讓後續整串都改變,導致差異很大而跑 diff algorithm 的效果不好:

用 File-by-File 的好處主要來自於是對未壓縮的檔案比較差異,這代表沒有變動的檔案完全不會進來攪和,而對 binary 檔案的效果也比較好 (大部份的程式碼還是一樣)。不過這對於已經有壓縮的圖片的效果就比較差了,這也是 APK 一般肥大常見的原因。

有兩件事情值得注意的,一個是 Google 的人為了使用者體驗,只有在 auto update 時才會走 File-by-File 的更新,主要原因是 File-by-File 的解開速度慢不少:

For now, we are limiting the use of this new patching technology to auto-updates only, i.e. the updates that take place in the background, usually at night when your phone is plugged into power and you're not likely to be using it. This ensures that users won't have to wait any longer than usual for an update to finish when manually updating an app.

另外一個是,這個新方式讓 Google 每天省下 6PB 的流量,如果流量都是平均打散的話,大約是 600Gbps:

The savings, compared to our previous approach, add up to 6 petabytes of user data saved per day!

這種規模改善起來很有感覺 XDDD

Amazon EFS 脫離測試期

Amazon EFS 其實就當作是 NFS/CIFS as a service,之前一直在測試期,現在正式宣佈進入 Production 了:「Amazon Elastic File System – Production-Ready in Three Regions」。

開放三個區域使用:

I am happy to announce that EFS is now available for production use in the US East (Northern Virginia), US West (Oregon), and Europe (Ireland) Regions.

不知道穩定性如何 XDDD (因為 Amazon EBS 之前的穩定性太有名...)

之前在測試的時候發現只支援 NFSv4,不支援 NFSv3,這樣有點可惜... 另外價錢也頗高的 :o

用 hosts 搞出來的 Adblock...

在「Amalgamated hosts file」這邊看到超大包的 hosts,拿來擋廣告:

This repo consolidates several reputable hosts files and merges them into a single amalgamated hosts file with duplicates removed.

Currently this amalgamated hosts file contains 27,148 unique entries.

一包 hosts 有兩萬七千筆資料會不會太多了點...

話說不知道能不能 import 進 BIND 或是 Unbound 裡面直接讓整個組織用?

取得某些 tld 所有的 Domain Name

在「How to Download a List of All Registered Domain Names」這邊介紹了 .com、.net 以及 .name 的 zone file 怎麼申請與下載 (由 Verisign 維護的三個 tld)。

另外也介紹了 Centralized Zone Data Service,包括所有的 tld,以及 ICANN 提供的 API。

這樣應該有很多資料可以分析?

IRCCloud 的檔案上傳功能...

IRCCloud 宣佈的新功能:「File Uploads」。

CloudFront 擋在前面,而且不是 Price Class 100 (因為 mtr 時至少有看到亞洲區的 PoP),不過看起來後面不是 S3...

在公告的文章裡有提到 Imgur,現在 Imgur 的 CDN 品質好像不是很好?台灣連過去用的是 Fastly 美國的點,但選點好像不太行啊?不過算是堪用...

innodb_file_per_table 對於 CREATE TABLE 與 DROP TABLE 的速度

雖然平常應該不會常常用到 CREATE TABLEDROP TABLE,不過還是很有趣的 benchmark:「Is MySQL’s innodb_file_per_table slowing you down?」。

重點在這段:

  • With innodb_file_per_table=ON
    • Schema and table creation = 1m54.852s
    • Schema drops = 1m21.682s
  • With innodb_file_per_table=OFF
  • Schema and table creation = 0m59.968s
  • Schema drops = 0m54.870s

不過作者測試時沒有用 ENGINE=COMPRESSED (必須在 innodb_file_per_table 打開時才支援,而且這也是選擇打開 innodb_file_per_table 的重要因素),不知道壓縮開起來以後會差多少...

不過就算再怎麼慢,相較於 CREATE TABLEDROP TABLE 的效能,還是比較計較壓縮換來的 I/O 效能。(尤其是資料量超過記憶體大小時)

Salt 要做到「當某個檔案存在時,執行某個指令」的方法...

愈用愈有感覺 SaltStack 是一堆 workaround 的集合,一開始在設計整個系統時沒有規劃好,然後一直堆上去。

標題的這個問題是出自於 Ubuntu 預設會將 CPU 調節成 ondemand,方式是透過 /etc/rc*.d/ 下的 symbolic link 在開機時自動執行。

拔掉的方法是 updated-rc.d ondemand disable (而非直接砍掉 /etc/rc*.d/ 裡面的檔案),想要透過 SaltStack 提供的 file.exists 或 file.missing 都發現不可行。

最後是 cmd.run + onlyif + test 搞定:

ondemand-disable:
  cmd.run:
    - name: update-rc.d ondemand disable
    - onlyif: test -e /etc/rc2.d/S99ondemand

SaltStack 對於 dependency 的設計看起來問題重重,如果想要用 SaltStack 的人可以好好考慮一下。

現在的作法是直接 trial and error 跟他拼,PuppetChefSaltStack 都直接用時間跟他換。原因是這東西實在太底層了,架構不好就是上面的管理員與 DevOps 一直 workaround。

現在有種互相在比爛的感覺...

Hjson:the Human JSON

前幾天看到「Hjson, the Human JSON」這東西,想要在 JSON 上面提出拓展,讓人更好維護。

有幾個設計是大家已經想很久了。

首先是允許註解:

{
  # specify rate in requests/second
  "rate": 1000
}

再來是允許 ending trailing comma,這點在新的 JavaScript Engine 裡面是允許的,但在 JSON 規格裡是不允許的,對於 copy-paste 時就得很小心有沒有中獎:

{
  one: 1,
  two: 2,
}

另外幾個特點就還好。

object 的 key 沒有特殊情況時可以省略 double quote:

{
  key: "value"
}

甚至 value 是 single line 時也可以省略:

{
  text: look ma, no quotes!
}

而且當沒有 double quote 時不需要處理 escape 問題:

{
  path: c:\windows
  inject: <div class="important"></div>

  # escapes work inside quotes
  escape: "c:\\windows"
}

然後逗點可以省略,給的範例也突顯出對腦袋不直覺的問題 (ambiguous),這邊的 1 是 integer 還是 string?

{
  one: 1
  two: 2
}

多行,用 ''' 應該是借用了 Python 的想法?

{
  haiku:
    '''
    JSON I love you.
    But strangled is my data.
    This, so much better.
    '''
}

規格後面有提到 syntax,可以看到定義。

Hjson 算是一個開始吧,YAML 的設計需要極長的 training 時間才能正確使用,不知道 SaltStack 會不會有人馬上寫 adapter 出來接?(因為 SaltStack 已經可以接 JSON 與 YAML,只要有人把該接的接上去就可以了)