Peningkatan Kinerja

2020-10-31

Posting ini akan menjelaskan panduan kinerja yang saya berikan kepada tim saya minggu lalu. Kami mengalami beberapa masalah dengan salah satu layanan kami karena perubahan konfigurasi. Perubahan tersebut melipatgandakan pemrosesan rata-rata waktu untuk satu pesan. Lebih tepatnya, perubahan terjadi di pemetaan data DSL, yang membantu analis menjelaskan bagaimana data masukan dipetakan ke data keluaran. Baca lebih lanjut tentang itu sini sini. Saya mengambil minggu ini untuk membuat layanan berjalan dengan kecepatan yang wajar lagi. Di bawah ini Anda akan menemukan pendekatan yang saya ambil, saat mencoba meningkatkan diri kinerja aplikasi.

Penafian: Akan ada banyak asumsi dan panduan sering berbicara tentang pemrosesan pesan. Saya mengerti bahwa ini tidak benar mewakili setiap aplikasi, tetapi prinsip inti yang disebutkan dalam Bagian “Prasyarat” masih berlaku. Saya kebanyakan menggunakan istilah itu „Aplikasi“ di sini, namun yang saya maksud adalah semua jenis perangkat lunak, baik itu a layanan backend, aplikasi frontend atau skrip sederhana.

Motivasi

graph showing average provessing time per message

Ada berbagai macam alasan, mengapa kinerja suatu aplikasi perlu ditingkatkan:

  1. Aplikasi akan dapat berjalan lebih efisien [1] .
  2. Aplikasi harus berjalan lebih cepat agar layak dijalankan sama sekali, agar ekonomis.
  3. Kinerja adalah keunggulan kompetitif [2] .
  4. Standar pengembang yang tinggi tidak terpenuhi.
  5. Dan banyak lainnya: Perilaku runtime yang lebih stabil dan dapat diprediksi, peningkatan beban di masa mendatang, membangun basis yang kuat untuk fitur masa depan.

Prasyarat

Untuk benar-benar memengaruhi kinerja aplikasi, Anda harus memenuhi beberapa persyaratan. Ada kebutuhan menjadi keterukuran . Anda harus bisa mengukur metrik yang ingin Anda turunkan / naikkan. Kamu bisa rekam itu oleh melakukan tolok ukur lokal atau dengan benar-benar melaporkan metrik ke backend metrik (Prometheus, CloudWatch, atau serupa). Meskipun yang terakhir mungkin kasar.

Hal berikutnya yang Anda inginkan adalah reproduktifitas , Anda harus dapat mereproduksi hasil pengukuran Anda hasil. Anda aplikasi harus dapat memproses n pesan yang sama dalam jumlah waktu yang sama. Juga memutar ulang yang sama data masukan harus bekerja dengan mudah. Ini sebenarnya bisa sangat sulit, jika aplikasi Anda bergantung pada eksternal sistem seperti database, broker pesan atau cloud-thingy lainnya; Saya akan membahasnya nanti.

Bagian terakhir adalah pembuatan profil , yang memungkinkan Anda menelusuri apa yang dibelanjakan aplikasi Anda waktunya terus. Nya wajib agar Anda dapat menyelidiki komponen aplikasi mana yang harus Anda tingkatkan: Jika aplikasi Anda adalah menghabiskan 80% waktu CPU-nya pada penguraian JSON, Anda mungkin harus fokus pada area itu. Mungkin beralih ke yang lebih cepat parser atau format serialisasi yang berbeda seperti protobuf. Jangan mengerjakan 20% lainnya itu, peningkatan Anda tidak akan terlalu berdampak. Untuk membuat profil grafik api adalah pilihan yang baik, untuk skrip yang lebih kecil Anda mungkin bisa instrumenkan kodenya sendiri.

Untuk meringkas: Anda ingin mengukur, mereproduksi, dan membuat profil perilaku waktu proses aplikasi Anda.

Pendekatan

Tentukan sendiri tujuan dan kerangka waktu. Keduanya bisa menjadi perkiraan kasar, tetapi Anda harus tetap berpegang pada mereka. Bekerja pada kinerja bisa menjadi lubang kelinci rumit yang diisi dengan optimisasi mikro dan sumpah yang intensif. Memiliki rencana untuk tetap membuat Anda fokus pada kemenangan besar. Ini bisa sesederhana: „Minggu ini saya akan meningkatkan throughput pesan (metrik yang dapat diukur!) dengan setidaknya 10 persen poin “. Di sisi lain kamu tidak boleh membuat tekanan yang tidak perlu untuk diri Anda sendiri, jika masalah kinerja dapat dikurangi dengan wajar jumlah perangkat keras tambahan, lakukanlah! Jumlah perangkat keras yang Anda dapatkan dibandingkan dengan beberapa jam kerja besar. Ini seharusnya tidak menjadi solusi default Anda.

Saatnya mengotori tangan, Anda harus dapat memulai aplikasi Anda secara lokal dan memasukkan data ke dalamnya. Lebih disukai Anda ingin memotong sistem eksternal seperti database jarak jauh. Bisakah Anda mengekstrak logika bisnis inti Anda dari keluhan kotor pengambilan data jarak jauh? Bagus, siapkan versi mandiri aplikasi Anda, yang bisa membaca masukan dari file atau database lokal. Jika tidak, lakukan yang terbaik untuk setidaknya membuat data masukan Anda deterministik. Kerja dengan tabel database yang dibekukan atau baca ulang topik Kafka dari titik yang diketahui. Jika Anda mengalami kesulitan dengan bahwa, mungkin bijaksana untuk meluangkan waktu di muka dan bekerja lebih baik dalam memisahkan masalah dalam diri Anda aplikasi. Pengetahuan tentang tempat penyimpanan dan pengiriman data Anda tidak boleh bocor ke sisi bisnis hal-hal, dorong kekhawatiran itu ke tepi aplikasi Anda. Item berikutnya dalam daftar adalah membuat a pengukuran dasar, sesuatu yang nanti dapat Anda gunakan untuk membuat perbandingan. Saya penggemar mendokumentasikan itu pengukuran dalam spreadsheet. Ini membantu menghitung perbedaan dan memungkinkan Anda mendokumentasikan perubahan di masa mendatang.

Sekarang Anda akhirnya bisa masuk ke dalam berbagai hal, menjalankan versi benchmark / standalone dan memasang profiler. Anda mungkin sudah memiliki beberapa kecurigaan tentang apa yang mungkin memperlambat aplikasi, konfirmasikan nomor yang sebenarnya. Mungkin juga ada banyak buah yang tergantung rendah, yang hanya membutuhkan beberapa menit untuk diperbaiki, tetapi secara total akan sudah membuat dampak yang nyata. Jika Anda menemukan dosa kinerja lainnya, dokumentasikan dan prioritaskan menurut perkiraan dampak dan upaya perbaikannya. Sekarang bilas dan ulangi: Perbaiki masalah, validasi file perbaikan, profil dan mulai lagi.

Kesalahan Umum

Beberapa hal umum yang mungkin Anda temui saat mencoba meningkatkan kinerja aplikasi:

  • Sebenarnya statis nilai-nilai yang akan sangat sering dihitung ulang dan secara mengejutkan mahal untuk dilakukan. Saya menemukan ekspresi reguler yang dikompilasi ulang dari string lebih dari 500 kali per pesan masukan. Sumber string diketahui saat aplikasi dimulai.
  • Kumpulan barang dihitung, tetapi sebagian besar hasilnya akan dibuang nanti. Jika iterasi Anda selesai koleksi untuk menghitung sesuatu untuk setiap item dan kemudian melakukan collection.find (...) panggilan, kamu mungkin ingin menggunakan koleksi malas.
  • Jika satu item dalam koleksi selalu dicari dengan kunci tertentu: Gunakan struktur data dengan O (1) akses seperti peta hash, bukan urutan. Secara umum: gunakan struktur data yang benar untuk pekerjaan itu di tangan. Mungkin Anda dikenakan biaya untuk mengubah larik JSON menjadi peta, tetapi biaya itu akan mengamortisasi dirinya sendiri secara mengejutkan cepat.
  • Complete Rewrite ™ mungkin bukan solusi untuk masalah performa Anda.

Kesimpulan

Pekerjaan kinerja itu menyenangkan dan bermanfaat. Meskipun ada rintangan untuk menetapkan tolok ukur yang dapat direproduksi, Anda bisa dijalankan secara lokal, benchmark ini akan terbayar. Ini juga merupakan hal yang berguna untuk mereproduksi beberapa dari mereka serangga yang lebih jahat. Meningkatkan kinerja inti aplikasi Anda akan menawarkan wawasan yang mendalam tentang Anda bahasa pemrograman pilihan dan membuat Anda lebih mahir dengannya. Pekerjaan kinerja bukanlah tugas satu kali Anda lakukan sekali, Anda harus terus memantau dan mengukur aplikasi Anda karena akan berubah seiring waktu.

Catatan

Pos lainnya

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments