Jawaban singkat: pada arsip 27.392.000 byte berisi 69 berkas, zstd 1.5.5 level 3 menghasilkan 7.867.772 byte dalam 0,32 detik, sedangkan gzip 1.12 level 9 menghasilkan 8.189.127 byte dalam 1,85 detik. Artinya zstd unggul dua-duanya: berkasnya 3,9 persen lebih kecil dan prosesnya 5,8 kali lebih cepat. xz 5.4.5 level 6 hanya menang tipis di ukuran (5.874.648 byte) tapi menuntut 25,39 detik, atau 79 kali lebih lama daripada zstd level 3.
- TL;DR zstd level 3 adalah titik seimbang: 28,7 persen dari ukuran asli, 0,32 detik.
- gzip level 9 kalah di dua sisi sekaligus: 29,9 persen ukuran, 1,85 detik.
- zstd level 19 dan xz level 6 sama-sama butuh sekitar 26 detik untuk tambahan 7 poin rasio.
- zstd level 1 (0,25 detik) cocok untuk arsip yang sering dibongkar-pasang kembali.
- Semua angka diukur ulang di host Ubuntu 24.04.5, kernel 6.8.0-147, 3 vCPU, RAM 3.915 MB.
Perbandingan ini bukan kutipan dari dokumentasi atau benchmark pihak lain. Isinya hasil pengukuran langsung pada satu berkas tar yang sama, dijalankan berurutan di mesin yang sama, dengan alat yang tersedia di distribusi. Tujuannya sederhana: memberi angka yang bisa diuji ulang sendiri oleh siapa pun yang punya berkas tar dan tiga utilitas kompresi.
Metodologi pengukuran
Bahan ujinya adalah salinan direktori src proyek web yang berisi 69 berkas, sebagian besar berkas teks berukuran kecil sampai sedang. Direktori itu dibungkus lebih dulu menjadi satu berkas tar berukuran 27.392.000 byte, lalu berkas tar yang sama dikompresi berulang kali. Semua proses berjalan single-thread, tanpa opsi pembagian thread seperti -T0 pada zstd atau pigz, supaya perbandingannya setara.
Waktu diambil dengan /usr/bin/time memakai format %e yang mengukur waktu dinding. Setiap mode dijalankan minimal satu kali untuk pemanasan cache halaman kernel, kecuali gzip level 1 yang dijalankan tiga kali berturut-turut untuk melihat sebaran hasil. Hasil gzip level 1 konsisten di kisaran 0,51 sampai 0,52 detik, jadi variasi antar-run di mesin ini kecil dan angka satu kali jalan pada mode lain masih layak dipakai sebagai perbandingan.
Versi alat yang diuji: zstd 1.5.5, gzip 1.12, dan xz 5.4.5. Ketiganya adalah versi bawaan yang terpasang di /usr/bin pada host uji, bukan hasil kompilasi khusus, jadi angka ini mendekati apa yang akan didapat pembaca yang memakai paket distribusi standar.
Berapa hasil lengkap tiap mode kompresi?
Lima mode diuji pada berkas tar yang identik. Kolom persen menunjukkan perbandingan ukuran hasil kompresi terhadap 27.392.000 byte asli, jadi makin kecil makin baik dari sisi ukuran.
| Alat dan level | Waktu | Ukuran hasil | Persen dari asli |
|---|---|---|---|
| zstd -1 | 0,25 detik | 9.034.722 byte | 33,0 persen |
| zstd -3 | 0,32 detik | 7.867.772 byte | 28,7 persen |
| gzip -1 | 0,51 detik | 9.974.162 byte | 36,4 persen |
| gzip -9 | 1,85 detik | 8.189.127 byte | 29,9 persen |
| zstd -19 | 26,94 detik | 5.957.117 byte | 21,7 persen |
| xz -6 | 25,39 detik | 5.874.648 byte | 21,4 persen |
Pola yang muncul mudah dibaca. Menambah level pada gzip dari 1 ke 9 membeli 6,5 poin rasio dengan biaya waktu 3,6 kali lipat. Pada zstd, lompatan dari level 1 ke level 3 hanya menambah 0,07 detik tapi memangkas 4,3 poin rasio, dan itu justru lompatan paling murah di seluruh tabel. Sebaliknya, mendorong zstd dari level 3 ke level 19 membeli 7 poin rasio tambahan dengan harga 84 kali waktu, sementara xz level 6 memberi 7,3 poin dengan harga 79 kali waktu.
Alasan zstd level 3 menang di dua sisi
Karena zstd memakai jendela pencocokan yang lebih besar dan entropi coder yang lebih efisien daripada deflate milik gzip, sehingga pada level yang masih rendah ia sudah menangkap pola berulang yang butuh level tinggi di gzip. Pada data uji ini, hasil zstd level 3 lebih kecil dari gzip level 9 walaupun waktunya seperlima. Ini bukan anomali: deflate adalah format tahun 1990-an yang dirancang untuk memori dan kecepatan CPU era itu, sedangkan zstd membawa model kompresi yang jauh lebih baru, sehingga wajar bila kurva biaya-manfaatnya bergeser.
Perlu dicatat apa yang tidak diukur di sini: kecepatan dekompresi dan konsumsi memori saat kompresi. Keduanya penting untuk keputusan produksi, terutama bila arsip dibongkar berkali-kali atau bila proses kompresi berjalan di kontainer dengan batas memori ketat. Tanpa angka dekompresi dari mesin yang sama, klaim soal kecepatan bongkar arsip sebaiknya tidak dibuat. Yang bisa dipastikan dari data di atas hanya sisi kompresi.
Kapan sebaiknya pakai gzip, zstd, atau xz?
| Kebutuhan | Pilihan | Alasan dari data ukur |
|---|---|---|
| Arsip yang dibongkar berkali-kali saat deploy | zstd -1 | 0,25 detik, tercepat di tabel dengan rasio masih 33 persen |
| Backup rutin yang disimpan lama | zstd -3 | 28,7 persen ukuran dengan waktu 0,32 detik |
| Distribusi berkas yang wajib dibaca alat lama | gzip -9 | satu-satunya pilihan bila penerima hanya punya gunzip |
| Arsip final sekali bikin, jarang dibuka | xz -6 | 21,4 persen ukuran, terkecil di tabel |
| Server dengan CPU ketat tapi bandwidth longgar | gzip -1 | 0,51 detik, 36,4 persen, beban CPU paling ringan dari keluarga gzip |
Untuk pengiriman lewat HTTP, pilihan ditentukan oleh apa yang disepakati klien lewat header Accept-Encoding. gzip masih paling aman karena diterima semua peramban dan pustaka HTTP lama, sementara zstd baru didukung sebagian klien. Bila server dan klien dua-duanya Anda kendalikan, zstd di lapisan transportasi memberi rasio lebih baik pada CPU yang sama, tapi itu klaim yang perlu diukur ulang di jalur jaringan Anda sendiri, bukan disimpulkan dari tabel di atas.
Apakah hasil tabel ini bisa dipakai untuk semua jenis data?
Tidak. Data uji di sini adalah kode sumber dan teks, yang pola berulangnya banyak. Berkas yang sudah terkompresi, seperti JPEG, WebP, MP4, atau arsip zip, hampir tidak bisa dipadatkan lagi oleh alat apa pun, dan level tinggi hanya membuang waktu. Berkas biner besar dengan sedikit redundansi, misalnya model machine learning, juga memberi rasio jauh lebih kecil. Karena itu, sebelum memilih level, ukur dulu pada 100 sampai 200 MB data Anda sendiri, bukan pada data contoh orang lain.
Cara mengukur cepat: siapkan satu berkas tar berisi data nyata, jalankan tiga perintah dengan level yang paling mungkin dipakai, dan catat waktu serta ukuran hasilnya. Perintahnya cukup satu baris per alat, misalnya zstd -3 -k untuk menyisakan berkas asli, atau gzip -9 -k untuk perilaku yang sama di gzip. Jangan lupa mengosongkan cache halaman bila ingin angka yang benar-benar netral, atau jalankan tiap mode dua kali dan pakai hasil kedua supaya efek cache sudah stabil.
Memasukkan pilihan ini ke pipeline deploy
Pada praktiknya, kompresi jarang berdiri sendiri. Arsip dibuat, diunggah, lalu dibongkar di server lain, dan pilihan alat menentukan berapa banyak waktu yang dihabiskan di tiap tahap. Untuk alur deploy, dua hal yang paling menentukan adalah waktu kompresi di mesin build dan dukungan alat di mesin tujuan. Bila kedua mesin Anda kendalikan dan keduanya punya zstd, memakai level 3 menghilangkan hampir seluruh waktu tunggu tanpa mengorbankan ukuran dibanding gzip level 9.
Untuk arsip yang dibongkar lewat tar, tar modern sudah mengenali opsi --zstd sehingga tidak perlu pipeline tambahan. Pada host uji ini tar dan zstd berasal dari paket distribusi yang sama, jadi kombinasinya tersedia tanpa pemasangan tambahan. Bila mesin tujuan hanya punya gunzip, kompresi harus tetap memakai gzip, dan pilihan level 1 versus level 9 menjadi keputusan antara 0,51 detik dengan 9.974.162 byte atau 1,85 detik dengan 8.189.127 byte pada data uji ini.
Hal yang sering terlewat adalah checksum. Arsip yang dikirim lewat jaringan sebaiknya membawa checksum supaya kerusakan byte saat transfer terdeteksi sebelum ekstraksi, bukan sesudah. Baik gzip, xz, maupun zstd menyimpan checksum di dalam formatnya, tapi kekuatannya berbeda. Untuk integritas yang serius, gabungkan dengan berkas hash SHA-256 terpisah dan verifikasi setelah unduhan selesai.
Terakhir, jangan membandingkan angka artikel ini dengan arsip yang isinya berbeda jenis. Data uji di sini adalah kode sumber, jadi rasionya bagus. Arsip berisi berkas yang sudah terkompresi, video, atau kumpulan biner besar akan memberi rasio jauh lebih rendah, dan pada kasus ekstrem kompresi hanya membuang waktu CPU tanpa penghematan berarti. Ukur sekali pada data Anda, simpan hasilnya di dokumentasi internal, lalu pakai angka itu sebagai dasar keputusan berikutnya.
FAQ
Apakah berkas zstd bisa dibuka dengan gunzip?
Tidak. zstd dan gzip memakai format kontainer berbeda, jadi gunzip akan menolak berkas .zst. Penerima wajib punya utilitas zstd, atau Anda harus mengemas ulang ke gzip. Untuk arsip yang tujuannya tidak Anda kendalikan, gzip masih pilihan paling aman.
Apakah zstd sudah tersedia di Ubuntu 24.04 tanpa install?
Di host uji ini zstd 1.5.5 sudah ada di /usr/bin/zstd, begitu juga gzip 1.12 dan xz 5.4.5. Pada instalasi minimal atau image kontainer yang dipangkas, ketiganya bisa saja belum ada, jadi periksa dulu dengan perintah command -v zstd sebelum menaruhnya di skrip otomatis.
Berapa rasio kompresi yang wajar untuk kode sumber?
Pada data uji ini rasio terbaik yang terukur adalah 21,4 persen dari ukuran asli, artinya berkas 27,4 MB menyusut jadi sekitar 5,9 MB. Untuk kode sumber yang mirip, kisaran 22 sampai 30 persen adalah ekspektasi yang wajar. Data yang sudah terkompresi akan jauh di atas itu, sering mendekati 95 sampai 100 persen.
Apakah level 19 layak dipakai untuk backup harian?
Hanya bila arsipnya dibuat sekali lalu jarang dibuka. Pada uji ini level 19 memakan 26,94 detik untuk berkas 27,4 MB, dan biaya itu naik seiring ukuran data. Untuk backup harian yang berjalan otomatis, zstd level 3 menyelesaikan pekerjaan yang sama dalam 0,32 detik dengan selisih ukuran hanya sekitar 7 poin persen.
Alat dan versi yang dipakai dalam pengukuran ini bisa diperiksa langsung di repositori resminya: zstd di GitHub, xz di tukaani.org, dan spesifikasi format gzip pada RFC 1952. Untuk membandingkan level secara mandiri, jalankan ulang perintah di atas pada data Anda sendiri dan pakai angka itu, bukan angka di artikel ini.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬