seaweedfs
3.80
SeaweedFS adalah proyek open source independen berlisensi Apache dengan pengembangan berkelanjutan yang dimungkinkan sepenuhnya berkat dukungan dari para pendukung yang luar biasa ini. Jika Anda ingin mengembangkan SeaweedFS lebih kuat lagi, silakan pertimbangkan untuk bergabung dengan sponsor kami di Patreon.
Dukungan Anda akan sangat dihargai oleh saya dan pendukung lainnya!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed atau weed.exe . Atau jalankan go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 untuk memulai satu master, satu server volume, satu filer, dan satu gateway S3. Selain itu, untuk meningkatkan kapasitas, cukup tambahkan lebih banyak server volume dengan menjalankan weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 secara lokal, atau di mesin lain, atau di ribuan mesin. Hanya itu saja!
SeaweedFS adalah sistem file terdistribusi yang sederhana dan sangat skalabel. Ada dua tujuan:
SeaweedFS dimulai sebagai Object Store untuk menangani file kecil secara efisien. Alih-alih mengelola semua metadata file di master pusat, master pusat hanya mengelola volume di server volume, dan server volume ini mengelola file dan metadatanya. Hal ini mengurangi tekanan konkurensi dari master pusat dan menyebarkan metadata file ke server volume, memungkinkan akses file lebih cepat (O(1), biasanya hanya satu operasi pembacaan disk).
Hanya ada 40 byte overhead penyimpanan disk untuk setiap metadata file. Ini sangat sederhana dengan pembacaan disk O(1) sehingga Anda dapat menantang kinerjanya dengan kasus penggunaan Anda yang sebenarnya.
SeaweedFS dimulai dengan mengimplementasikan makalah desain Haystack milik Facebook. Selain itu, SeaweedFS mengimplementasikan pengkodean penghapusan dengan ide dari f4: Sistem Penyimpanan BLOB Hangat Facebook, dan memiliki banyak kesamaan dengan Sistem File Tectonic Facebook
Selain penyimpanan objek, Filer opsional dapat mendukung direktori dan atribut POSIX. Filer adalah server stateless terpisah yang dapat diskalakan secara linier dengan penyimpanan metadata yang dapat disesuaikan, misalnya, MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB, dll.
Untuk penyimpanan nilai kunci terdistribusi apa pun, nilai besar dapat dipindahkan ke SeaweedFS. Dengan kecepatan akses yang cepat dan kapasitas yang dapat diskalakan secara linier, SeaweedFS dapat berfungsi sebagai penyimpanan Nilai-Kunci-Besar yang terdistribusi.
SeaweedFS dapat berintegrasi secara transparan dengan cloud. Dengan data panas di klaster lokal, dan data hangat di cloud dengan waktu akses O(1), SeaweedFS dapat mencapai waktu akses lokal yang cepat dan kapasitas penyimpanan cloud yang elastis. Terlebih lagi, biaya API akses penyimpanan cloud diminimalkan. Lebih cepat dan lebih murah daripada penyimpanan cloud langsung!
Kembali ke Daftar Isi
Kembali ke Daftar Isi
Kembali ke Daftar Isi
Secara default, node master berjalan pada port 9333, dan node volume berjalan pada port 8080. Mari kita mulai satu node master, dan dua node volume pada port 8080 dan 8081. Idealnya, keduanya harus dimulai dari mesin yang berbeda. Kami akan menggunakan localhost sebagai contoh.
SeaweedFS menggunakan operasi HTTP REST untuk membaca, menulis, dan menghapus. Responsnya dalam format JSON atau JSONP.
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
Untuk mengunggah file: pertama, kirim permintaan HTTP POST, PUT, atau GET ke /dir/assign untuk mendapatkan fid dan URL server volume:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Kedua, untuk menyimpan konten file, kirim permintaan POST multi-bagian HTTP ke url + '/' + fid dari respons:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Untuk memperbarui, kirim permintaan POST lain dengan konten file yang diperbarui.
Untuk penghapusan, kirim permintaan HTTP DELETE ke url + '/' + fid URL:
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Sekarang, Anda dapat menyimpan fid , 3,01637037d6 dalam hal ini, ke bidang database.
Angka 3 di awal mewakili id volume. Setelah koma, ada satu kunci file, 01, dan satu cookie file, 637037d6.
Id volume adalah bilangan bulat 32-bit yang tidak ditandatangani. Kunci file adalah bilangan bulat 64-bit yang tidak ditandatangani. Cookie file adalah bilangan bulat 32-bit yang tidak ditandatangani, digunakan untuk mencegah tebakan URL.
Kunci file dan cookie file keduanya dikodekan dalam hex. Anda dapat menyimpan tuple <volume id, file key, file cookie> dalam format Anda sendiri, atau cukup menyimpan fid sebagai string.
Jika disimpan sebagai string, secara teori, Anda memerlukan 8+1+16+8=33 byte. Char(33) sudah cukup, jika tidak lebih dari cukup, karena sebagian besar penggunaan tidak memerlukan 2^32 volume.
Jika ruang benar-benar menjadi masalah, Anda dapat menyimpan id file dalam format Anda sendiri. Anda memerlukan satu bilangan bulat 4-byte untuk id volume, nomor panjang 8-byte untuk kunci file, dan bilangan bulat 4-byte untuk cookie file. Jadi 16 byte sudah lebih dari cukup.
Berikut adalah contoh cara merender URL.
Pertama-tama cari URL server volume berdasarkan volumeId file:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Karena (biasanya) server volume tidak terlalu banyak, dan volume tidak sering berpindah, Anda dapat menyimpan hasilnya dalam cache hampir sepanjang waktu. Bergantung pada jenis replikasi, satu volume dapat memiliki beberapa lokasi replika. Pilih saja satu lokasi secara acak untuk dibaca.
Sekarang Anda dapat mengambil URL publik, merender URL atau langsung membaca dari server volume melalui URL:
http://localhost:8080/3,01637037d6.jpg
Perhatikan kami menambahkan ekstensi file ".jpg" di sini. Ini opsional dan hanya salah satu cara bagi klien untuk menentukan tipe konten file.
Jika Anda menginginkan URL yang lebih bagus, Anda dapat menggunakan salah satu format URL alternatif berikut:
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
Jika Anda ingin mendapatkan versi gambar yang diperkecil, Anda dapat menambahkan beberapa parameter:
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS menerapkan strategi replikasi pada tingkat volume. Jadi, ketika Anda mendapatkan id file, Anda dapat menentukan strategi replikasi. Misalnya:
curl http://localhost:9333/dir/assign?replication=001
Opsi parameter replikasi adalah:
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
Rincian lebih lanjut tentang replikasi dapat ditemukan di wiki.
Anda juga dapat mengatur strategi replikasi default saat memulai server master.
Server volume dapat dimulai dengan nama pusat data tertentu:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
Saat meminta kunci file, parameter opsional "dataCenter" dapat membatasi volume yang ditetapkan ke pusat data tertentu. Misalnya, ini menetapkan bahwa volume yang ditetapkan harus dibatasi hingga 'dc1':
http://localhost:9333/dir/assign?dataCenter=dc1
Kembali ke Daftar Isi
Biasanya sistem file terdistribusi membagi setiap file menjadi beberapa bagian, master pusat menyimpan pemetaan nama file, indeks potongan ke pegangan potongan, dan juga potongan mana yang dimiliki setiap server potongan.
Kelemahan utamanya adalah master pusat tidak dapat menangani banyak file kecil secara efisien, dan karena semua permintaan baca harus melalui master chunk, sehingga mungkin tidak dapat diskalakan dengan baik untuk banyak pengguna secara bersamaan.
Daripada mengelola potongan, SeaweedFS mengelola volume data di server master. Setiap volume data berukuran 32GB, dan dapat menampung banyak file. Dan setiap node penyimpanan dapat memiliki banyak volume data. Jadi node master hanya perlu menyimpan metadata tentang volume, yang merupakan jumlah data yang cukup kecil dan umumnya stabil.
Metadata file sebenarnya disimpan di setiap volume di server volume. Karena setiap server volume hanya mengelola metadata file di disknya sendiri, dengan hanya 16 byte untuk setiap file, semua akses file dapat membaca metadata file hanya dari memori dan hanya memerlukan satu operasi disk untuk benar-benar membaca data file.
Sebagai perbandingan, struktur inode xfs di Linux berukuran 536 byte.
Arsitekturnya cukup sederhana. Data aktual disimpan dalam volume pada node penyimpanan. Satu server volume dapat memiliki beberapa volume, dan keduanya dapat mendukung akses baca dan tulis dengan autentikasi dasar.
Semua volume dikelola oleh server master. Server master berisi id volume ke pemetaan server volume. Ini adalah informasi yang cukup statis, dan dapat dengan mudah di-cache.
Pada setiap permintaan tulis, server master juga menghasilkan kunci file, yang merupakan bilangan bulat 64-bit yang tidak ditandatangani. Karena permintaan tulis umumnya tidak sesering permintaan baca, satu server master harus mampu menangani konkurensi dengan baik.
Ketika klien mengirimkan permintaan tulis, server master mengembalikan (id volume, kunci file, cookie file, URL node volume) untuk file tersebut. Klien kemudian menghubungi node volume dan POST konten file.
Ketika klien perlu membaca file berdasarkan (id volume, kunci file, cookie file), klien meminta server master berdasarkan id volume untuk (URL simpul volume, URL publik simpul volume), atau mengambilnya dari cache. Kemudian klien dapat MENDAPATKAN kontennya, atau cukup merender URL di halaman web dan membiarkan browser mengambil konten tersebut.
Silakan lihat contoh untuk detail proses tulis-baca.
Dalam implementasi saat ini, setiap volume dapat menampung 32 gibibyte (32GiB atau 8x2^32 byte). Ini karena kami menyelaraskan konten ke 8 byte. Kita dapat dengan mudah meningkatkannya menjadi 64GiB, atau 128GiB, atau lebih, dengan mengubah 2 baris kode, dengan mengorbankan beberapa ruang padding yang terbuang karena penyelarasan.
Volumenya bisa mencapai 4 gibibyte (4GiB atau 2^32 byte). Jadi total ukuran sistem adalah 8 x 4GiB x 4GiB yaitu 128 exbibytes (128EiB atau 2^67 bytes).
Setiap ukuran file individual dibatasi oleh ukuran volume.
Semua informasi meta file yang disimpan di server volume dapat dibaca dari memori tanpa akses disk. Setiap file hanya membutuhkan entri peta 16-byte <kunci 64bit, offset 32bit, ukuran 32bit>. Tentu saja, setiap entri peta memiliki biaya ruang sendiri untuk peta tersebut. Namun biasanya ruang disk habis sebelum memori habis.
Server volume lokal jauh lebih cepat, sedangkan penyimpanan cloud memiliki kapasitas elastis dan sebenarnya lebih hemat biaya jika tidak sering diakses (biasanya gratis untuk diunggah, namun relatif mahal untuk diakses). Dengan struktur tambahan saja dan waktu akses O(1), SeaweedFS dapat memanfaatkan penyimpanan lokal dan cloud dengan memindahkan data hangat ke cloud.
Biasanya data panas adalah data segar dan data hangat adalah data lama. SeaweedFS menempatkan volume yang baru dibuat di server lokal, dan secara opsional mengunggah volume lama ke cloud. Jika data lama lebih jarang diakses, ini memberi Anda kapasitas tak terbatas dengan server lokal terbatas, dan tetap cepat untuk data baru.
Dengan waktu akses O(1), biaya latensi jaringan dijaga agar tetap minimum.
Jika data panas/hangat dibagi 20/80, dengan 20 server, Anda dapat mencapai kapasitas penyimpanan 100 server. Itu penghematan biaya sebesar 80%! Atau Anda dapat menggunakan kembali 80 server untuk menyimpan data baru juga, dan mendapatkan throughput penyimpanan 5X.
Kembali ke Daftar Isi
Kebanyakan sistem file terdistribusi lainnya tampak lebih rumit dari yang diperlukan.
SeaweedFS dimaksudkan agar cepat dan sederhana, baik dalam pengaturan maupun pengoperasian. Jika Anda tidak memahami cara kerjanya saat Anda sampai di sini, kami gagal! Silakan ajukan masalah jika ada pertanyaan atau perbarui file ini dengan klarifikasi.
SeaweedFS terus bergerak maju. Sama dengan sistem lain. Perbandingan ini bisa menjadi usang dengan cepat. Tolong bantu untuk terus memperbaruinya.
Kembali ke Daftar Isi
HDFS menggunakan pendekatan potongan untuk setiap file, dan ideal untuk menyimpan file besar.
SeaweedFS ideal untuk menyajikan file yang relatif lebih kecil dengan cepat dan bersamaan.
SeaweedFS juga dapat menyimpan file ekstra besar dengan membaginya menjadi potongan data yang dapat dikelola, dan menyimpan id file dari potongan data tersebut ke dalam potongan meta. Ini dikelola oleh alat "unggah/unduh gulma", dan master gulma atau server volume tidak peduli tentang hal itu.
Kembali ke Daftar Isi
Arsitekturnya sebagian besar sama. SeaweedFS bertujuan untuk menyimpan dan membaca file dengan cepat, dengan arsitektur yang sederhana dan datar. Perbedaan utamanya adalah
| Sistem | Metadata Berkas | Konten File Dibaca | POSIX | API REST | Dioptimalkan untuk sejumlah besar file kecil |
|---|---|---|---|---|---|
| Rumput LautFS | id volume pencarian, dapat di-cache | O(1) pencarian disk | Ya | Ya | |
| Filer FS Rumput Laut | Dapat Diskalakan Secara Linear, Dapat Disesuaikan | O(1) pencarian disk | SEKERING | Ya | Ya |
| GlusterFS | hashing | SEKERING, NFS | |||
| Ceph | hashing + aturan | SEKERING | Ya | ||
| RusaFS | dalam memori | SEKERING | TIDAK | ||
| MiniO | file meta terpisah untuk setiap file | Ya | TIDAK |
Kembali ke Daftar Isi
GlusterFS menyimpan file, baik direktori maupun konten, dalam volume yang dapat dikonfigurasi yang disebut "brick".
GlusterFS meng-hash jalur dan nama file ke dalam id, dan ditetapkan ke volume virtual, lalu dipetakan ke "bata".
Kembali ke Daftar Isi
MooseFS memilih untuk mengabaikan masalah file kecil. Dari manual moosefs 3.0, "bahkan file kecil akan menempati 64KiB ditambah tambahan 4KiB checksum dan 1KiB untuk header", karena "pada awalnya dirancang untuk menyimpan file yang sangat besar dalam jumlah besar (seperti beberapa ribu)"
MooseFS Master Server menyimpan semua meta data di memori. Masalah yang sama dengan namenode HDFS.
Kembali ke Daftar Isi
Ceph dapat diatur mirip dengan SeaweedFS sebagai penyimpanan kunci->blob. Ini jauh lebih rumit, dengan kebutuhan untuk mendukung lapisan di atasnya. Berikut perbandingan lebih detailnya
SeaweedFS memiliki grup master terpusat untuk mencari volume gratis, sementara Ceph menggunakan server hashing dan metadata untuk menemukan lokasi objeknya. Memiliki master terpusat memudahkan pembuatan kode dan pengelolaan.
Ceph, seperti SeaweedFS, didasarkan pada penyimpanan objek RADOS. Ceph agak rumit dengan tinjauan yang beragam.
Ceph menggunakan hashing CRUSH untuk mengelola penempatan data secara otomatis, yang efisien untuk menemukan lokasi data. Namun datanya harus ditempatkan sesuai dengan algoritma CRUSH. Konfigurasi yang salah akan menyebabkan hilangnya data. Perubahan topologi seperti penambahan server baru untuk meningkatkan kapasitas akan menyebabkan migrasi data dengan biaya IO yang tinggi agar sesuai dengan algoritma CRUSH. SeaweedFS menempatkan data dengan menugaskannya ke volume apa pun yang dapat ditulis. Jika penulisan ke satu volume gagal, pilih saja volume lain untuk ditulis. Menambahkan lebih banyak volume juga sesederhana mungkin.
SeaweedFS dioptimalkan untuk file kecil. File kecil disimpan sebagai satu blok konten yang berkesinambungan, dengan paling banyak 8 byte yang tidak terpakai di antara file. Akses file kecil adalah pembacaan disk O(1).
SeaweedFS Filer menggunakan penyimpanan siap pakai, seperti MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, untuk mengelola direktori file. Toko-toko ini terbukti, terukur, dan lebih mudah dikelola.
| Rumput LautFS | sebanding dengan Ceph | keuntungan |
|---|---|---|
| Menguasai | MDS | lebih sederhana |
| Volume | OSD | dioptimalkan untuk file kecil |
| Pengarsip | Ceph FS | dapat diskalakan secara linier, Dapat disesuaikan, O(1) atau O(logN) |
Kembali ke Daftar Isi
MinIO mengikuti AWS S3 dengan cermat dan ideal untuk pengujian API S3. Ini memiliki UI yang bagus, kebijakan, versi, dll. SeaweedFS mencoba mengejar ketinggalan di sini. Dimungkinkan juga untuk menempatkan MinIO sebagai gateway di depan SeaweedFS nanti.
Metadata MinIO ada dalam file sederhana. Setiap penulisan file akan menimbulkan penulisan tambahan ke file meta yang sesuai.
MinIO tidak memiliki optimasi untuk banyak file kecil. File-file tersebut disimpan apa adanya di disk lokal. Ditambah file meta tambahan dan pecahan untuk pengkodean penghapusan, itu hanya memperburuk masalah LOSF.
MinIO memiliki beberapa IO disk untuk membaca satu file. SeaweedFS memiliki pembacaan disk O(1), bahkan untuk menghapus file berkode.
MinIO memiliki pengkodean penghapusan penuh waktu. SeaweedFS menggunakan replikasi pada data panas untuk kecepatan lebih cepat dan secara opsional menerapkan pengkodean penghapusan pada data hangat.
MinIO tidak memiliki dukungan API seperti POSIX.
MinIO memiliki persyaratan khusus pada tata letak penyimpanan. Tidak fleksibel untuk menyesuaikan kapasitas. Di SeaweedFS, cukup mulai satu server volume yang menunjuk ke master. Itu saja.
Ini adalah proyek yang sangat menarik! Dan kami membutuhkan pembantu dan dukungan!
Kembali ke Daftar Isi
Panduan instalasi untuk pengguna yang belum familiar dengan golang
Langkah 1: instal di mesin Anda dan atur lingkungan dengan mengikuti instruksi di:
https://golang.org/doc/install
pastikan untuk mendefinisikan $GOPATH Anda
Langkah 2: periksa repo ini:
git clone https://github.com/seaweedfs/seaweedfs.gitLangkah 3: unduh, kompilasi, dan instal proyek dengan menjalankan perintah berikut
cd seaweedfs/weed && make install Setelah ini selesai, Anda akan menemukan "weed" yang dapat dieksekusi di direktori $GOPATH/bin Anda
Kembali ke Daftar Isi
Saat menguji kinerja baca di SeaweedFS, ini pada dasarnya menjadi tes kinerja kecepatan baca acak hard drive Anda. Hard drive biasanya mendapatkan 100MB/s~200MB/s.
Untuk mengubah atau menghapus file kecil, SSD harus menghapus seluruh blok sekaligus, dan memindahkan konten di blok yang ada ke blok baru. SSD cepat ketika masih baru, namun akan terfragmentasi seiring berjalannya waktu dan Anda harus mengumpulkan sampah, memadatkan blok. SeaweedFS ramah terhadap SSD karena hanya bersifat tambahan. Penghapusan dan pemadatan dilakukan pada tingkat volume di latar belakang, tidak memperlambat pembacaan dan tidak menyebabkan fragmentasi.
Kembali ke Daftar Isi
Hasil Mesin Tunggal Tidak Ilmiah Saya Sendiri di Mac Book dengan Solid State Disk, CPU: 1 Intel Core i7 2.6GHz.
Tulis 1 juta file 1KB:
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
Membaca 1 juta file secara acak:
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
Untuk melihat statistik permintaan tersegmentasi, gunakan parameter --analyze.v.
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
Kembali ke Daftar Isi
Berlisensi di bawah Lisensi Apache, Versi 2.0 ("Lisensi"); Anda tidak boleh menggunakan file ini kecuali sesuai dengan Lisensi. Anda dapat memperoleh salinan Lisensi di
http://www.apache.org/licenses/LICENSE-2.0
Kecuali diwajibkan oleh undang-undang yang berlaku atau disetujui secara tertulis, perangkat lunak yang didistribusikan berdasarkan Lisensi didistribusikan berdasarkan DASAR "APA ADANYA", TANPA JAMINAN ATAU KETENTUAN DALAM BENTUK APAPUN, baik tersurat maupun tersirat. Lihat Lisensi untuk bahasa tertentu yang mengatur izin dan batasan berdasarkan Lisensi.
Teks halaman ini tersedia untuk dimodifikasi dan digunakan kembali berdasarkan ketentuan Lisensi Creative Commons Attribution-Sharealike 3.0 Unported dan Lisensi Dokumentasi Gratis GNU (tidak berversi, tanpa bagian invarian, teks sampul depan, atau teks sampul belakang).
Kembali ke Daftar Isi
