DigiLoog

続きを読む »

アーカイブの展開速度はアルゴリズム・CPU処理速度・ディスクアクセスで大体決まるが、
圧縮速度は上記の3つが複雑に絡まる上、対象ファイルの容量も重要な速度要素となる。
純粋に比較するなら前回と同じ環境がベストだが、6年前と同じ環境を揃えるのは無理なので、
趣向を変えて誰でも同じ条件を再現出来るVPSを使いつつ複数回測定する方針に変更した。

● 実行環境

1. 新規にサーバインスタンスを作成し、CentOS Stream 9をテンプレートインストール
2. インストール直後に”dnf update”を実行して2022年02月05日の最新状態へアップデート
3. OSチューニングは行わず、出来る限り素の状態に近くして計測開始

● コマンドバージョン

● 計測方法

1. バイナリファイルとテキストファイルに対して各圧縮コマンドを実行
2. 各コマンド事に6回の圧縮処理を実行する事で計測ブレを極力無くす
3. 圧縮率指定が出来るコマンドは、速度重視・指定無し・圧縮重視の3種類を測定
   ただし、アーカイブ化(＝無圧縮)オプションは計測を省略する
4. 時間計測にはLinuxのtimeコマンドを使い、real時間をファイル圧縮に要した時間とする
5. 圧縮率は『圧縮後のファイルサイズ ÷ 圧縮前のファイルサイズ』で算出
6. 圧縮対象の元ファイルは下記を利用
   テキストファイルは1度展開した後にtarコマンドで無圧縮アーカイブに固め直して計測

今回は対象コマンドや計測回数が増加したので、次の様なスクリプトを実行して放置した。
コマンドを連発しているので仮想ホスト側で制限がかかる可能性もあるが、
気にしたらベアメタルサーバを持ち出さないとダメになるので諦めた。

#!/bin/sh

date
echo

for LIST in `ls | egrep -iv "(bench|tmp)"`
do
    echo ${LIST}
    time gzip -c ${LIST} > ${LIST}.gz
    echo "---"
done

ls -l
du -l
rm -rf *.gz

………

計測結果の生データとCSVファイルは下記ダウンロードリンクを参照。
そのままのデータなので二次加工もしやすい筈。

今回の計測条件で測定してみたらバイナリとテキストの両方とも7zipが圧倒的に速かった。
前回の時は7zipの処理速度が若干早い中、バランスが取れているのはbzip2の印象だったが、
内部処理が変わったのか躍進していた。
意外なのはxz形式でソースコードの圧縮でも利用される中、圧縮率重視の7zipには負けた。

圧縮率と処理速度の両方とも好成績なのがWindows利用されるrar形式だった。
テキストはそこまで圧縮出来なかったが、
バイナリは96.5%近くまで圧縮しつつ処理速度が2分程度という驚異の結果となった。
xz形式で同じ容量まで圧縮すると10分要する事からも、rarの完成度が出てきた結果となる。

Linuxで良く利用されるgzip・bzip2・xzは前回同様にバランスが取れた結果となった。
デファクトスタンダードとして使われる事が多い三つだが、
不得手なく処理出来るからこそ安定した圧縮率と処理速度を誇っていた。

結果をグラフにしたら、LZMA/LZMA2アルゴリズムを使うxz・7zip形式の速度が顕著になった。
その分、圧縮率が高いので処理速度が遅いのは仕方ない部分もあるが、
同種のアルゴリズムなのにxzと7zipで1.5～2.0倍の速度差が出ているのが気になった。

“ns-lab BB”は現行サーバ基盤へ刷新した時にログの圧縮形式をxzに変更したが、
ここまで顕著に速度差が出るなら7zipを試したい気持ちも若干出てきた。
だがkernelソースでも利用されているxzや、根強く認識のあるgzipはまだ現役な上、
Linuxで7zipは使い勝手が悪いのも事実だったりする。
そんな事もあり、当面はgzip・xzの二強と、間を補完するbzip2を使う事になると思われる。

6年前の計測結果から若干変わった結果となったが、デファクトスタンダードは早々変わらないので、
今後もgzip・bzip2・xzの三つがLinuxで使われる事となりそうだった。
でも、利用シーンによっては違う圧縮形式が選択肢になり得る事を把握した上でベストを選びたい。

« 続きを隠す