Tolok Ukur Kafka
Artikel ini memperkenalkan metode uji kinerja Kafka dan laporan Tolok Ukur secara rinci.
Pengujian kinerja dan alat pemantauan cluster
Kafka menyediakan banyak alat yang bermanfaat, seperti Analisis Desain Kafka (3) -Kafka High Availability (Bagian 2) Alat operasi dan pemeliharaan yang disebutkan di bagian-Alat Penetapan Ulang Partisi, Alat Pemilihan Pemimpin Replika Pilihan, Alat Verifikasi Replika, Alat Penggabungan Log Perubahan Status. Bab ini akan memperkenalkan alat pengujian kinerja yang disediakan oleh Kafka, alat pelaporan Metrik, dan Manajer Kafka sumber terbuka Yahoo.
Skrip tes kinerja Kafka
$ KAFKA_HOME / bin / kafka-producer-perf-test.sh Skrip ini dirancang untuk menguji kinerja Kafka Producer. Ini terutama mengeluarkan 4 indikator. Jumlah total pesan terkirim (dalam MB), jumlah pesan terkirim per detik (MB / detik), jumlah total pesan yang dikirim, jumlah pesan yang dikirim per detik (record / detik). Selain mengeluarkan hasil pengujian ke keluaran standar, skrip juga menyediakan Pelapor CSV, yaitu hasil disimpan dalam bentuk file CSV, yang memudahkan hasil pengujian dalam alat analisis lainnya.
$ KAFKA_HOME / bin / kafka-consumer-perf-test.sh Skrip ini digunakan untuk menguji kinerja Konsumen Kafka, dan indikator uji sama dengan skrip uji kinerja Produser
Metrik Kafka
Kafka menggunakan Metrik Yammer untuk melaporkan informasi metrik server dan klien. Yammer Metrics 3.1.0 menyediakan 6 bentuk Metrics collection-Meter, Gauges, Counter, Histograms, Timers, Health Checks. Pada saat yang sama, Metrik Yammer memisahkan kumpulan Metrik dari laporan (atau rilis) dan dapat digabungkan secara bebas sesuai kebutuhan. Saat ini mendukung Reporter Konsol, Reporter JMX, Reporter HTTP, Reporter CSV, Reporter SLF4J, Reporter Ganglia, Reporter Grafit. Oleh karena itu, Kafka juga mendukung keluaran informasi Metriknya melalui laporan di atas.
Gunakan JConsole untuk melihat metrik server tunggal
Menggunakan JConsole melalui JMX adalah salah satu cara termudah dan paling nyaman untuk melihat metrik server Kafka tanpa menginstal alat lain (karena Kafka sudah diinstal, Java harus diinstal, dan JConsole adalah alat yang disertakan dengan Java).
Pertama, Anda harus mengaktifkan Kafka's JMX Reporter dengan menetapkan nilai yang valid untuk variabel lingkungan JMX_PORT. Seperti ekspor JMX_PORT = 19797. Kemudian Anda dapat menggunakan JConsole untuk mengakses server Kafka melalui port yang diatur di atas untuk melihat informasi Metriknya, seperti yang ditunjukkan pada gambar berikut.
Salah satu keuntungan menggunakan JConsole adalah Anda tidak perlu menginstal alat tambahan. Kekurangannya jelas. Tampilan datanya tidak cukup intuitif, organisasi datanya tidak ramah, dan yang lebih penting, metrik dari seluruh cluster tidak dapat dipantau secara bersamaan. Pada gambar di atas, di kafka.cluster- > Partisi- > UnderReplicated- > Di bawah topic4, hanya ada dua node 2 dan 5. Ini bukan karena topic4 hanya memiliki data dari dua partisi ini dalam status replikasi. Faktanya, topic4 hanya memiliki dua Partisi ini di Broker ini, dan Partisi lainnya ada di Broker lain, jadi hanya dua Partisi ini yang dapat dilihat melalui Reporter JMX di server ini.
Lihat metrik seluruh cluster melalui Kafka Manager
Kafka Manager adalah alat manajemen Kafka open source Yahoo. Ini mendukung fungsi berikut
- Kelola beberapa cluster
- Lihat status cluster dengan mudah
- Lakukan pemilihan replika pilihan
- Buat dan jalankan rencana distribusi Partisi untuk berbagai topik dalam batch
- Buat Topik
- Hapus Topik (hanya mendukung 0.8.2 dan lebih tinggi, dan memerlukan delete.topic.en dapat disetel ke true di Broker)
- Tambahkan Partisi ke topik yang sudah ada
- Perbarui konfigurasi Topik
- Pada premis bahwa Pialang JMX Reporter dihidupkan, jajak pendapat Tingkat Pialang dan Metrik tingkat Topik
- Pantau Kelompok Konsumen dan status konsumsinya
- Mendukung penambahan dan tampilan LogKafka
Setelah Kafka Manager diinstal, akan sangat mudah untuk menambahkan Cluster. Anda hanya perlu menentukan daftar Zookeeper yang digunakan oleh Cluster dan menentukan versi Kafka, seperti yang ditunjukkan pada gambar berikut.
Perlu dicatat di sini bahwa menambahkan Cluster di sini berarti menambahkan cluster Kafka yang sudah ada ke daftar pemantauan, daripada menggunakan Cluster Kafka baru melalui Kafka Manager, yang berbeda dari Cloudera Manager.
Lingkungan pengujian kinerja Kafka
Salah satu fitur inti Kafka adalah tingkat throughput yang tinggi, jadi fokus pengujian artikel ini adalah tingkat throughput Kafka.
Pengujian dalam artikel ini menggunakan total 6 mesin virtual dengan Red Hat 6.6 terinstal, 3 sebagai Broker, dan 3 sebagai Produser atau Konsumen. Setiap mesin virtual dikonfigurasi sebagai berikut
- CPU: 8 vCPU, Intel (R) Xeon (R) CPU E5-2680 v2 @ 2.80GHz, 2 Soket, 4 Core per soket, 1 Thread per core
- Memori: 16 GB
- Disk: 500 GB
Buka Kafka JMX Reporter dan gunakan port 19797, dan gunakan fungsi polling JMX dari Kafka-Manager untuk memantau tingkat throughput selama uji kinerja.
Artikel ini terutama menguji empat skenario berikut: Indikator utama yang diuji adalah berapa megabyte data per detik dan berapa banyak pesan per detik.
Nomor Produsen VS. Throughput
- Kondisi eksperimental: 3 Broker, 1 Topik, 6 Partisi, tanpa Replikasi, mode asynchronous, payload pesan adalah 100 byte
- Item pengujian: Uji throughput masing-masing 1, 2, dan 3 Produser
- Tujuan pengujian: Seperti yang diperkenalkan dalam analisis desain Kafka (1) -Latar belakang Kafka dan pengenalan arsitektur, beberapa Produsen dapat mengirim data ke topik yang sama pada waktu yang sama. Sebelum beban Broker dipenuhi, secara teoritis, semakin banyak jumlah Produsen, semakin banyak cluster yang diterima per detik Volume berita yang lebih besar, dan peningkatan linier. Eksperimen ini terutama memverifikasi fitur ini. Pada saat yang sama sebagai pengujian kinerja, percobaan ini juga akan memantau penggunaan CPU dan memori dari satu Broker selama pengujian
- Hasil pengujian: total tingkat throughput saat menggunakan jumlah Produser yang berbeda ditunjukkan pada gambar di bawah ini
Seperti dapat dilihat dari gambar di atas, satu Produser berhasil mengirim sekitar 1,28 juta pesan dengan payload 100 byte per detik, dan dengan bertambahnya jumlah Produser, jumlah total pesan yang dikirim per detik meningkat secara linier, yang sejalan dengan analisis sebelumnya.
Selama uji kinerja, penggunaan CPU dan memori Broker ditunjukkan pada gambar di bawah ini.
Seperti yang dapat dilihat dari gambar di atas, ketika sekitar 1,17 juta pesan diterima per detik (total 3 Produsen mengirim 3,5 juta pesan per detik, dan masing-masing Broker menerima sekitar 1,17 juta pesan per detik), penggunaan CPU dari sebuah Broker adalah sekitar Apakah 248%, dan penggunaan memori 601 MB.
Ukuran Pesan VS Throughput
- Kondisi percobaan: 3 Broker, 1 Topik, 6 Partisi, tanpa Replikasi, mode asynchronous, 3 Produser
- Item pengujian: Uji total throughput cluster ketika panjang pesan masing-masing adalah 10, 20, 40, 60, 80, 100, 150, 200, 400, 800, 1000, 2000, 5000, 10000 byte
- Hasil pengujian: total throughput cluster pada panjang pesan yang berbeda ditunjukkan pada gambar di bawah ini
Seperti terlihat dari gambar di atas, semakin panjang pesan, semakin sedikit jumlah pesan yang dapat dikirim per detik, dan semakin besar jumlah pesan (MB) yang dapat dikirim per detik. Selain itu, selain payload, setiap pesan juga berisi metadata lain, sehingga jumlah pesan yang dikirim per detik lebih besar dari jumlah pesan yang dikirim per detik dikalikan 100 byte, dan semakin besar payload, semakin kecil proporsi metadata tersebut, dan dikirim pada waktu yang sama Semakin besar volume pesan yang dikirim dalam kelompok pada suatu waktu, semakin mudah untuk mendapatkan pesan yang lebih tinggi per detik (MB / s). Payload yang digunakan dalam pengujian lain adalah 100 byte Alasan menggunakan pesan singkat ini (relatif singkat) hanya untuk menguji tingkat throughput Kafka dalam kondisi yang relatif buruk.
Nomor Partisi VS. Throughput
- Kondisi percobaan: 3 Broker, 1 Topik, tanpa Replikasi, mode asynchronous, 3 Produser, payload pesan adalah 100 byte
- Item pengujian: Uji throughput masing-masing 1 hingga 9 Partisi
- Hasil pengujian: total throughput cluster dengan nomor partisi yang berbeda ditunjukkan pada gambar di bawah ini
Dapat dilihat dari gambar di atas bahwa ketika jumlah Partisi lebih kecil dari jumlah Broker (3), semakin besar jumlah Partisi, semakin tinggi tingkat throughput dan peningkatan linier. Dalam semua percobaan di artikel ini, hanya 3 Broker yang dimulai, dan Partisi hanya ada pada 1 Broker (Replikasi tidak dipertimbangkan. Bahkan jika ada Replikasi, hanya Pimpinannya yang menerima permintaan baca dan tulis), jadi ketika Topik hanya berisi 1 Selama Partisi, sebenarnya hanya ada satu Broker yang bekerja untuk topik tersebut. Seperti yang sudah disebutkan di artikel sebelumnya, Kafka akan meratakan semua Partisi ke semua Broker, jadi bila hanya ada 2 Partisi maka akan ada 2 Broker yang melayani topik tersebut. Jika ada 3 Partisi, maka akan ada 3 Broker yang melayani topik tersebut. Dengan kata lain, ketika jumlah Partisi kurang dari atau sama dengan 3, semakin banyak Partisi yang mewakili semakin banyak Broker yang melayani topik. Seperti yang disebutkan di artikel sebelumnya, data tentang Broker yang berbeda disisipkan secara paralel, yang menjelaskan bahwa ketika jumlah Partisi kurang dari atau sama dengan 3, laju throughput meningkat secara linier dengan bertambahnya jumlah Partisi.
Ketika jumlah Partisi lebih dari jumlah Broker, total throughput tidak meningkat, bahkan menurun. Alasan yang mungkin adalah ketika jumlah Partisi adalah 4 dan 5, jumlah Partisi pada Broker yang berbeda berbeda, dan Produser akan mengirimkan data secara merata ke setiap Partisi, yang menyebabkan beban setiap Broker berbeda dan tidak dapat memaksimalkan throughput cluster. Pada gambar di atas, ketika jumlah Partisi adalah kelipatan bilangan bulat dari jumlah Broker, throughput secara signifikan lebih tinggi daripada dalam kasus lain, yang juga menegaskan hal ini.
Nomor Replika VS. Throughput
- Kondisi percobaan: 3 Broker, 1 Topik, 6 Partisi, mode asynchronous, 3 Produser, payload pesan adalah 100 byte
- Item pengujian: tingkat throughput saat menguji 1 hingga 3 replika masing-masing
- Hasil pengujian: seperti yang ditunjukkan pada gambar di bawah ini
Seperti yang dapat dilihat dari gambar di atas, seiring dengan meningkatnya jumlah replika, laju throughput menurun. Namun, penurunan throughput rate tidak menurun secara linier, karena replikasi data dari beberapa followers dilakukan secara paralel dan bukan serial.
Nomor Konsumen Kafka VS. Throughput
- Kondisi eksperimental: 3 Broker, 1 Topik, 6 Partisi, tanpa Replikasi, mode asynchronous, payload pesan adalah 100 byte
- Item pengujian: total tingkat throughput cluster saat menguji masing-masing 1 hingga 3 Konsumen
- Hasil pengujian: Jika ada banyak pesan di cluster, total throughput cluster saat menggunakan 1 hingga 3 Konsumen ditunjukkan pada gambar di bawah ini
Seperti yang dapat dilihat dari gambar di atas, satu Konsumen dapat mengonsumsi 3,06 juta pesan per detik, yang jauh lebih besar daripada jumlah pesan per detik yang dapat dikonsumsi oleh satu Produsen. Hal ini memastikan bahwa pesan dapat diproses dalam waktu dengan konfigurasi yang wajar. Dan saat jumlah Konsumen meningkat, total throughput kluster meningkat secara linier.
berdasarkan Kafka Design Analysis (4) -Kafka Consumer Design Analysis Seperti yang disebutkan, ketika beberapa Konsumen menggunakan pesan, Partisi adalah unit alokasi. Jika hanya ada satu Konsumen, Konsumen perlu menarik pesan dari 6 Partisi pada saat yang sama. I / O dari mesin tempat Konsumen berada menjadi penghambat dari seluruh proses konsumsi. Ketika jumlah Konsumen meningkat menjadi 2 menjadi 3, beberapa Konsumen menarik pesan dari cluster pada saat yang sama, memanfaatkan sepenuhnya tingkat throughput cluster.
Pasangan Konsumen Produsen
- Kondisi eksperimental: 3 Broker, 1 Topik, 6 Partisi, tanpa Replikasi, mode asynchronous, payload pesan adalah 100 byte
- Item pengujian: Uji jumlah pesan yang dapat dikonsumsi Konsumen ketika 1 Produsen dan 1 Konsumen bekerja pada waktu yang sama
- Hasil tes: 1.215.613 catatan / detik
- Sepuluh inti dan 20 utas, platform X99 akan datang! 5000 yuan game lebih banyak konfigurasi host terbuka
- Pada Pertemuan Pembacaan dan Editor Musim Gugur Nanjing, orang-orang besar di surat kabar komputer memanggil Anda untuk "menghadapi basis"!
- Xiaomi Mix2 akhirnya mengantarkan pembaruan versi stabil, dan juga mendukung aplikasi buka kunci wajah