Home » Posts tagged "gzip"

Amazon API Gateway 支援壓縮了...

Amazon API Gateway 支援壓縮了:「Amazon API Gateway Supports Content Encoding for API Responses」。

You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.

打開後傳回的資料就會自動壓縮了,然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway),目前支援的壓縮格式應該是最常見的 gzipdeflate

這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...

Amazon Redshift 支援 Zstandard

Amazon Redshift 支援 Zstandard 壓縮資料:「Amazon Redshift now supports the Zstandard high data compression encoding and two new aggregate functions」。

Zstandard 是 Facebook 的人發展出來的壓縮與解壓縮方式,對比的對象主要是 zlib (或者說 gzip),官網上有不少比較圖。目標是希望在同樣的壓縮處理速度下,可以得到更好的壓縮率。

Redshift 支援 Zstandard 等於是讓現有使用 gzip 的使用者免費升級的感覺...

CloudFlare 對 Brotli 的測試

之前有提過這件事情,由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法),所以 CloudFlare 的人整理了目前的效能比較:「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率,對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率,從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%):

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助,但對於 on-the-fly 的壓縮反而會比較慢。

CloudFlare 加速 zlib library

CloudFlare 大幅改善 zlib,使得速度相較原來的版本快了許多:「Fighting Cancer: The Unexpected Benefit Of Open Sourcing Our Code」。

改變的部份主要是 CPU 指令集的特性,以及 longest-match function 的改善。可以看出不同的測試樣本 (corpus) 在壓縮率沒有變差的情況下,大幅改善了速度。

Calgary corpus

Canterbury corpus

Large corpus

Silesia corpus

速度快非常多,跟 Google 以壓縮率為導向而放出來的 zopfli 剛好是兩個極端:「Google 發表與 zlib/deflate 相容的壓縮程式,再小 5%...」。

Linux Kernel 將不提供 bzip2 格式了...

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 的第一個 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 發表與 zlib/deflate 相容的壓縮程式,再小 5%...

GoogleApache 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),但對於靜態內容的幫助會很大,因為壓一次後就可以用很多次。

Archives