幹壞事是進步最大的原動力
CloudFlare 大幅改善 zlib，使得速度相較原來的版本快了許多：「Fighting Cancer: The Unexpected Benefit Of Open Sourcing Our Code」。
改變的部份主要是 CPU 指令集的特性，以及 longest-match function 的改善。可以看出不同的測試樣本 (corpus) 在壓縮率沒有變差的情況下，大幅改善了速度。
速度快非常多，跟 Google 以壓縮率為導向而放出來的 zopfli 剛好是兩個極端：「Google 發表與 zlib/deflate 相容的壓縮程式，再小 5%...」。
在 kernel.org 上看到 Linux Kernel 將不提更 bzip2 格式的原始程式包了：「Happy new year and good-bye bzip2」。
之後只會提供 .tar.gz (為了廣泛的可用性) 與 .tar.xz (為了大小，降低傳輸量)。xz 壓出來小不少，也愈來愈多的單位在用了...
bzip2 也一陣子沒更新了，上次更新是 1.0.6，是為了安全性更新 CVE-2010-0405，而 1.0.5 也是安全性更新，真正有新版本是 1.0.4 (2006 年 12 月)。
算是功成身退了？
Percona XtraDB Cluster 5.6 的第一個 RC 版本公告出來了：「Percona XtraDB Cluster 5.6.15-25.2 first Release Candidate is now available」。
其他的說明沒什麼，但意外看到這點：
Percona XtraDB Cluster now supports stream compression/decompression with new xtrabackup-sst compressor/decompressor options.
在「option compressor/decompressor」這邊可以看到這個設定，功能是在傳輸 SST 的過程壓縮。
看了範例設定，似乎也可以使用 gzip 以外的方式？bzip2 或是 xz 應該是可行的方案？
對跨機房之間的 full resync 應該是有幫助的... 像是 IPsec 的處理能力沒那麼高的時候 :p
前幾天 Google 推出 Zopfli：「Google 發表與 zlib/deflate 相容的壓縮程式，再小 5%...」，是個壓縮率比目前實做的 deflate/zlib 還高的新演算法。
而 Zopflinator 則是提供比較的網站，你可以把網址丟進去後看到未壓縮的大小、用 deflate 預設值壓縮後的大小，gzip -9 的大小，以及 zopfli 後的大小。
原文出自 Steve Souders 的「Zopflinator」...
Google 以 Apache License, Version 2.0 發表了與 zlib/deflate 相容的壓縮程式：「Compress Data More Densely with Zopfli」。
與 zlib/deflate 相容代表現有的 browser 都不需要變動，而在 project 頁面上是這樣寫：
Zopfli Compression Algorithm is a new zlib (gzip, deflate) compatible compressor. This compressor takes more time (~100x slower), but compresses around 5% better than zlib and better than any other zlib-compatible compressor we have found.
比起現有的 zlib-compatible compressor 大約慢 100 倍 (XDDD)，但對於靜態內容的幫助會很大，因為壓一次後就可以用很多次。
今天花了不少時間找到的問題...
問題是使用 mod_fastcgi 以及 mod_deflate 時，Content-Encoding 會是 gzip，但 Content-Length 會是未壓縮的長度。
也就是說，伺服器端在 header 提供的 Content-Length 可能寫 8KB，但實際上只丟出 2KB (壓縮後的大小)，於是瀏覽器讀完這 2KB 後會停下來一直等，等到 Keep-Alive timeout 斷線 (在我機器上預設是 5 秒)。
在 timeout 斷線後 browser 會就抓到的資料直接解開執行 (因為這 2KB 都有抓到，於是都正確執行)。如果用瀏覽器這邊的 debugger 觀察，就會發現從 first byte 後 5.00 秒才 document ready。
解法有人在 2008 年給過：「Content-Length header should be set using ap_set_content_length」，不過因為 mod_fastcgi 一直沒出新的正式版，所以大家都還是拿到舊的版本。
所以，與之前修正 multi-threading 的問題一樣，往 ports 本身丟 patch：「Update www/mod_fastcgi to fix mod_deflate issue.」，修正後再測試就正常了。
在「gzip support for Amazon Web Services CloudFront」這篇提到了要如何用 CloudFront 的 Custom Origin 實做標準 deflate/gzip。
之前 CloudFront 就有支援 Vary header，雖然只支援 Accept-Encoding，但這就是我們要的：(Appendix: Custom Origins)
The only acceptable value for the Vary header is Accept-Encoding.
本來 S3 沒有能力依據 Accept-Encoding 送出不同的結果，這次有了 Custom Origin 出來以後掛個有能力 gzip-on-the-fly 的 Web Server 就可以做到了，檔案也不一定要放到 S3 上 (可以放 EBS)。
基本上這個功能可以用現有的外部機器做 (因為 CloudFront 連到 Origin 的量應該不大)，或是 EC2 的 micro instance 應該也夠用了...