Laporan Teknis Uji Beban Internal
Credits dengan bangga mempersembahkan hasil dari Tahap Pertama Pengujian Platform . Pada hari Jumat, 14 September 2018, tim Kredit melakukan tes kapasitas platform Kredit menggunakan 32 node yang didistribusikan secara geografis. Tes ini dirancang untuk menampilkan platform stabil dan memberikan indikasi transaksi per detik (TPS) dengan tingkat transaksi simulasi yang tinggi.
Periksa pengujian streaming langsung YouTube dari Credits:
Kondisi pengujian
- 32 node dengan sistem operasi Windows dan Linux yang dimaksudkan untuk menunjukkan interoperabilitas lintas-platform;
- Node berada di 5 negara — Kanada, Jerman, Australia, Polandia, Latvia untuk menyediakan lingkungan pengujian terdistribusi secara geografis yang realistis;
- 5 node dilengkapi dengan generator transaksi untuk mensimulasikan pemuatan jaringan;
- Peningkatan beban Jaringan disimulasikan dengan menambahkan 275 transaksi per detik hingga beban maksimum tercapai.
Jika Anda tertarik dengan informasi yang lebih rinci, silakan baca artikel lengkap tentang kondisi Internal Load Test.
Laporan pengujian
Ringkasan Informasi dari Credits Blockchain dan Kredit selama Uji Fase 1.
Uji waktu dalam hitungan menit
39 Menit
Jumlah total transaksi
305,136,000 Transaksi
Jumlah total blok
5 923 Blok
Uji Progresi
275 Transaksi Tambahan ditambahkan ke Antrian dengan Setiap Pass
Jumlah Transaksi Rata-rata per blok
85, 200 Transaksi per blok
Jumlah Puncak Transaksi dalam Satu Blok
685,122 Transaksi per blok
Jumlah rata-rata Blok per detik
2 Blok Per detik
Jumlah Puncak Blok per detik
6 Blok Per detik
Transaksi Rata-rata per detik
130.400 Transaksi per detik
Jumlah Puncak Transaksi per detik
- 327.152 Transaksi per detik
Informasi Terperinci tentang Tes Beban Internal Tahap 1 dari alat OS Windows dan utilitas freeware
Gambar 1 — Test Environment Configuration
Untuk mensimulasikan kinerja jaringan dalam lingkungan yang realistis kami menggunakan jaringan yang terdiri dari Virtual Machines (VM), dengan masing-masing spesifikasi yang ditunjukkan pada Gambar. 1. VM ditempatkan di berbagai lokasi geografis di alamat IP yang berbeda. Perangkat lunak node menggabungkan komputer-komputer ini ke jaringan mikro, yang pada gilirannya berkomunikasi satu sama lain melalui NAT. Selain perangkat lunak node, kami memasang perangkat lunak pemantauan tambahan untuk mengukur kinerja VMs.
Gambar 2 — Alokasi RAM VM melalui Sysinternals Suite
Gambar 2 mengilustrasikan penggunaan RAM pada VM selama operasi node. Gambar menunjukkan alokasi RAM pada salah satu tes VM yang disediakan dengan bantuan RamMap dari Sysinternals. Node menggunakan volume memori yang signifikan yang dialokasikan untuk proses pribadi dan file yang dipetakan.
Gambar 3 — Proses Operasi Node
Gambar 3 menampilkan proses simpul (client.exe) secara terpisah dari proses lain yang berjalan di komputer. Penggunaan memori setelah satu jam operasi ditampilkan. Ini skala sebanding dengan penggunaan sistem RAM secara keseluruhan. Node adalah proses yang paling intensif sumber daya yang berjalan di mesin virtual.
Gambar 4 — Dampak Database LevelDB pada Operasi Node
Di sini dampak operasi database terisolasi dalam node (client.exe). Akun operasi database untuk hampir sepertiga dari memori dalam proses node.
Gambar 5 — Memori yang Digunakan oleh File Node Executable.
Dari gambar ini jelas bahwa memori sebagian besar dialokasikan untuk LevelDB database yang digunakan dalam sistem daripada file yang dapat dieksekusi itu sendiri, karena beratnya hanya 412 Kb.
Gambar 6 — Penggunaan CPU Node
Gambar 6 menampilkan dampak dari node (client.exe) pada CPU. Node hampir sepenuhnya memuat CPU dengan operasi node.
Gambar 7 — Penggunaan Memori Setelah 1 Jam Operasi.
Sistem Memory Usage dibandingkan dengan Node Memory Usage (3 rd grafik dari bawah) yang mempengaruhi memori yang digunakan oleh node (garis kuning pada 3 rd grafik dari bawah) dan memori yang digunakan oleh proses sistem lainnya. Harap dicatat bahwa penggunaan RAM yang tinggi menyebabkan kesalahan keras dalam sistem. Pada awal uji coba, node menggunakan sekitar 1/3 RAM, namun setelah 1 jam hampir semua RAM sistem dikonsumsi oleh database node. Setelah RAM sistem habis, node mulai menimpa sel basis data yang mengakibatkan kesalahan keras. Ketika database berjalan di memori, seluruh node terkena dampak negatif.
The Optimasi database berikut diperlukan:
- Penambahan batasan otomatis atau manual dari penggunaan memori (mirip dengan file paging atau memori untuk mesin virtual Java);
- Memperbaiki semua kebocoran memori.
Gambar 8 — Node Impact on Storage
Gambar 8 menunjukkan interaksi node dengan penyimpanan sistem (hard drive). Grafik menunjukkan operasi yang berkinerja dalam rentang yang diharapkan. Sedikit peningkatan dalam kecepatan operasi (puncak pada grafik) dapat dilakukan dengan mengganti hard drive dengan drive solid state yang lebih efisien. Drive yang lebih cepat meningkatkan operasi karena data node akan membutuhkan lebih sedikit waktu untuk membaca dan menulis antrian ke disk.
Gambar 9 — Interaksi Node, Jaringan, dan Sinyal Server
Node secara aktif berkomunikasi dengan lingkungan eksternal dan node lainnya. Karena tidak ada komunikasi internet lain atau aplikasi web yang berjalan pada mesin virtual pengujian, hampir semua lalu lintas diambil oleh node mengirim dan menerima fungsi. Lalu lintas internet itu sendiri tidak signifikan, sehingga sebuah node yang berjalan di jaringan komputer internal minimal berdampak pada mesin lain yang mencoba menggunakan internet pada saat yang bersamaan.
Gambar 10 — Konsumsi Sumber Daya Sistem
Warna merah adalah konsumsi prosesor dari program client.exe, hijau menampilkan proses lainnya. Konsumsi sumber daya komputer ditunjukkan dengan cara yang lebih rinci. Saat pengujian berlangsung, baik memori sistem dan sumber daya CPU benar-benar habis. Revisi lebih lanjut dari perangkat lunak node akan menempatkan pembatasan pada konsumsi memori dan input-output, IO, operasi.
Gambar 11 — Aktivitas node jaringan (tanpa generator transaksi)
Warna ungu — lalu lintas yang dihasilkan oleh simpul kerja, kuning — lainnya. Dengan nol aktivitas jaringan, tidak ada yang ditulis ke disk, karena semua data disimpan dalam RAM.
Gambar 12 — Node aktivitas jaringan (dengan generator transaksi).
Warna ungu — lalu lintas yang dihasilkan oleh simpul kerja, kuning — lainnya. Jendela konsol menunjukkan node yang bekerja pada blok yang berisi transaksi. Selama proses ini data node dipertukarkan dengan hard drive. Ketika aktivitas Jaringan meningkat, periode aktivitas tanpa transaksi, seperti yang ditunjukkan pada Gambar. 11, menjadi hampir tidak terlihat dibandingkan dengan pemrosesan transaksi puncak karena penskalaan otomatis dalam grafik.
Gambar 13 — Interaksi node dengan memori konstan .
Rilis Tes tidak dioptimalkan untuk meminimalkan ruang hard disk. Pertumbuhan blockchain dan kebutuhan untuk menyalin sejarah lengkap dari semua transaksi sistem ke setiap node yang tidak dipercaya adalah kerugian dari semua teknologi blockchain. Penggunaan klien Web dan dompet ringan adalah salah satu solusi untuk ini.
Pertanyaan:
Kami ingin memberikan jawaban atas pertanyaan paling populer dari komunitas Credits mengenai streaming langsung.
1) Apakah server sinyal akan dihapus?
Ya, penghapusan server sinyal ada di roadmap pengembangan internal kami. Versi perangkat lunak yang akan datang, kemungkinan bertepatan dengan pengujian Tahap 3 harus memiliki hambatan potensial dan hambatan untuk desentralisasi dihapus, dengan fungsinya yang dipindahkan ke kode perangkat lunak node.
2) Mengapa saldo simpul menunjukkan nilai 0 selama streaming langsung?
Ada kesalahan API dalam kode perangkat lunak situs web monitor yang mendasari yang digunakan selama Uji Fase 1. Laporan bug telah dicatat, dengan perbaikan sudah selesai. Versi selanjutnya dari perangkat lunak monitor tidak akan menunjukkan cacat ini.
3) Selama sesi pengujian langsung singkat, sekitar 17 gigabyte data dihasilkan. Bagaimana jumlah besar data ini akan ditangani dalam skenario produksi?
Ukuran data blockchain sedang dioptimalkan untuk ukuran dan panjang transaksi. Keuntungan penyimpanan tambahan akan dibuat dengan memanfaatkan kompresi data dalam database. Diharapkan bahwa produk yang dirilis akan memiliki kompresi yang jauh lebih baik yang sesuai untuk situasi produksi dan penggunaan node.
4) Mengapa grafik Transaksi Per Detik (TPS) tidak berkorelasi dengan informasi di halaman muka Monitor?
Grafik TPS menunjukkan jumlah transaksi rata-rata selama periode waktu 30 detik. The Credits Monitor (halaman rumah) menunjukkan jumlah transaksi dalam satu blok.
5) Apa faktor-faktor yang menentukan waktu pemrosesan block?
Waktu pemrosesan blok sebagian besar dipengaruhi oleh latensi bandwidth. Faktor tambahan adalah jumlah data signifikan 11,5 MB yang termasuk dalam satu blok.
6) Mengapa beberapa block kosong?
Generator Transaksi dikembangkan untuk mensimulasikan lingkungan kehidupan nyata, oleh karena itu logis untuk memiliki interval tanpa transaksi dalam block.
