Saya melakukan perdagangan algoritmik di Raiffeisenbank. Ini adalah area yang agak spesifik dari sektor perbankan. Kami membuat platform perdagangan yang berfungsi dengan penundaan yang rendah dan dapat diprediksi. Keberhasilan aplikasi tergantung, antara lain, pada kecepatan aplikasi, jadi kita harus berurusan dengan seluruh tumpukan yang terlibat dalam perdagangan: saluran jaringan pribadi, perangkat keras khusus, pengaturan OS dan JVM khusus, dan, tentu saja, aplikasi itu sendiri. Kami tidak dapat berhenti mengoptimalkan aplikasi itu sendiri secara eksklusif - pengaturan OS atau jaringan tidak kalah penting. Ini membutuhkan keahlian teknis dan pengetahuan untuk memahami bagaimana data mengalir melalui seluruh tumpukan, dan di mana mungkin ada penundaan.
Tidak semua organisasi / bank mampu mengembangkan perangkat lunak kelas ini. Tetapi saya beruntung bahwa proyek seperti itu diluncurkan di dalam dinding Raiffeisenbank, dan saya memiliki spesialisasi yang sesuai - Saya berspesialisasi dalam kinerja kode di Intel Moscow Compiler Laboratory. Kami membuat kompiler untuk C, C ++ dan Fortran. Di Raiffeisenbank, saya pindah ke Jawa. Jika sebelumnya saya membuat semacam alat yang digunakan banyak orang saat itu, sekarang saya telah pindah ke sisi lain dari barikade dan saya terlibat dalam analisis terapan kinerja tidak hanya kode, tetapi seluruh tumpukan aplikasi. Secara teratur, cara untuk meneliti masalah kinerja terletak jauh di luar kode, misalnya, di pengaturan kernel atau jaringan.
Java bukan untuk beban tinggi?
Dipercaya secara luas bahwa Java tidak terlalu cocok untuk pengembangan sistem yang sangat dimuat.
Ini hanya sebagian yang bisa disepakati. Jawa indah dalam banyak aspek. Jika kita membandingkannya dengan bahasa seperti C ++, maka potensi overhead-nya mungkin lebih tinggi, tetapi kadang-kadang solusi yang serupa secara fungsional di C ++ dapat bekerja lebih lambat. Ada optimisasi yang secara otomatis berfungsi di Java, tetapi tidak berfungsi di C ++, dan sebaliknya. Melihat kualitas kode yang muncul setelah kompiler Java JIT, saya ingin percaya bahwa kinerja akan lebih rendah daripada apa yang dapat saya capai di puncak, tidak lebih dari beberapa kali. Tetapi pada saat yang sama saya mendapatkan pengembangan yang sangat cepat, peralatan yang sangat baik, dan berbagai pilihan komponen yang tersedia.
Mari kita hadapi itu: di dunia C ++, lingkungan pengembangan (IDE) secara signifikan di belakang IntelliJ dan Eclipse. Jika pengembang menggunakan salah satu dari lingkungan ini, maka kecepatan debug, menemukan bug dan menulis logika kompleks adalah urutan besarnya lebih tinggi. Sebagai hasilnya, ternyata lebih mudah untuk mengarsipkan Java di tempat yang tepat sehingga bekerja cukup cepat daripada melakukan semuanya dari awal dan untuk waktu yang sangat lama di C ++. Yang paling lucu adalah ketika menulis kode kompetitif, pendekatan sinkronisasi di Jawa dan C ++ sangat mirip: mereka adalah primitif level OS (misalnya,
disinkronkan / std :: mutex ) atau primitif besi (
Atom * / std :: atomic <*> ) . Dan sangat penting untuk melihat kesamaan ini.
Secara umum, kami sedang mengembangkan aplikasi non-beban tinggi))
Apa perbedaan antara aplikasi latensi tinggi dan rendah?
Istilah highload tidak sepenuhnya mencerminkan spesifikasi pekerjaan kami - kami terlibat dalam
sistem latensi-sentitif . Apa bedanya? Untuk sistem yang sarat muatan, penting untuk bekerja rata-rata dengan cukup cepat, memanfaatkan sumber daya perangkat keras sepenuhnya. Dalam praktiknya, ini berarti bahwa setiap juta permintaan ke sistem ke seratus / keseribu / ribu dapat berpotensi bekerja sangat lambat, karena kami fokus pada nilai rata-rata dan tidak selalu memperhitungkan bahwa pengguna kami menderita rem yang signifikan.
Kami terlibat dalam sistem yang tingkat keterlambatannya sangat penting. Tugas kami adalah memastikan bahwa sistem selalu memiliki respons yang dapat diprediksi.
Sistem yang berpotensi
sensitif terhadap latensi mungkin tidak dimuat secara penuh jika peristiwa jarang terjadi, tetapi waktu respons yang dijamin diperlukan. Dan itu tidak membuat perkembangan mereka lebih mudah. Justru sebaliknya! Bahaya menunggu di mana-mana. Sebagian besar komponen perangkat keras dan lunak modern berorientasi pada kerja yang baik "rata-rata", yaitu. untuk
throughput .
Ambil setidaknya struktur data. Kami menggunakan tabel hash, dan jika re-hash dari seluruh struktur data terjadi pada jalur kritis, ini dapat menyebabkan rem yang nyata untuk pengguna tertentu berdasarkan satu permintaan. Atau JIT compiler - mengoptimalkan pola kode yang paling sering dieksekusi, pesimisasi pola kode yang jarang dieksekusi. Tetapi kecepatan kasus langka ini bisa sangat penting bagi kami!
Mungkin kode ini memproses jenis pesanan yang langka? Atau situasi pasar yang tidak biasa yang membutuhkan respons cepat? Kami berusaha memastikan bahwa reaksi sistem kami terhadap peristiwa yang berpotensi langka ini memerlukan waktu yang dapat diprediksi dan, terutama, sangat singkat.
Bagaimana cara mencapai waktu reaksi yang dapat diprediksi?
Pertanyaan ini tidak dapat dijawab dalam dua frasa. Dalam perkiraan pertama, penting untuk memahami apakah ada jenis sinkronisasi -
disinkronkan, reentrantlock atau sesuatu dari
java.util.concurrent . Seringkali Anda harus menggunakan sinkronisasi pada busy-spin'ah. Menggunakan sinkronisasi primitif apa pun selalu merupakan kompromi. Dan penting untuk memahami bagaimana sinkronisasi primitif ini bekerja dan pertukaran apa yang mereka lakukan. Penting juga untuk mengevaluasi berapa banyak sampah yang dihasilkan oleh sepotong kode tertentu. Cara terbaik untuk memerangi pemulung adalah dengan tidak memicunya. Semakin sedikit kita akan menghasilkan sampah, semakin sedikit kita akan menjalankan pengumpul sampah, dan semakin lama sistem akan bekerja tanpa intervensi.
Kami juga menggunakan berbagai alat yang berbeda yang memungkinkan kami untuk menganalisis tidak hanya indikator rata-rata. Kita harus hati-hati menganalisis seberapa lambat sistem bekerja setiap kali keseratus, setiap kali keseribu. Jelas, indikator-indikator ini akan lebih buruk daripada median atau rata-rata. Tetapi sangat penting bagi kita untuk mengetahui berapa banyak. Dan alat-alat seperti
Grafana ,
Prometheus ,
histogram HDR, dan
JMH membantu menunjukkan hal ini.
Bisakah saya menghapus Tidak Aman?
Seringkali Anda harus menggunakan apa yang oleh apologis disebut sebagai API tidak berdokumen. Saya sedang berbicara tentang Unsafe yang terkenal. Saya percaya tidak aman telah menjadi bagian de facto dari API publik mesin Java. Tidak masuk akal untuk menyangkalnya. Unsafe menggunakan banyak proyek yang kita semua gunakan secara aktif. Dan jika kita menolaknya, lalu apa yang akan terjadi pada proyek-proyek ini? Entah mereka akan hidup di Jawa versi lama, atau mereka lagi harus menghabiskan banyak energi untuk menulis ulang semua ini. Apakah masyarakat siap untuk ini? Apakah siap untuk berpotensi kehilangan puluhan persen produktivitas? Dan yang paling penting, dengan imbalan apa?
Secara tidak langsung, pendapat saya mengkonfirmasi
penghapusan metode yang
sangat rapi dari Unsafe - di Java11 metode yang paling tidak berguna dari Unsafe dihapus. Saya pikir bahwa sampai setidaknya setengah dari semua proyek yang menggunakan Unsafe pindah ke yang lain, Unsafe akan tersedia dalam satu atau lain bentuk.
Ada pendapat: Bank + Java = perusahaan keras yang berdarah?
Tim kami tidak memiliki kengerian seperti itu. Di Spring, kami mungkin menulis sepuluh baris, dan oleh saya)) Kami mencoba untuk tidak menggunakan teknologi besar. Kami lebih suka melakukan hal-hal kecil, rapi, dan cepat, sehingga kami dapat menyadarinya, mengendalikannya, dan, jika perlu, memodifikasinya. Yang terakhir ini sangat penting untuk sistem (seperti kita), yang tunduk pada persyaratan non-standar, yang mungkin berbeda dari persyaratan 90% dari pengguna kerangka kerja. Dan dalam hal menggunakan kerangka kerja yang besar, kita tidak akan dapat menyampaikan kebutuhan kita kepada masyarakat atau untuk memperbaiki perilaku secara mandiri.
Menurut pendapat saya, pengembang harus selalu dapat menggunakan semua alat yang tersedia. Saya datang ke dunia Java dari C ++ dan saya sangat terkesan oleh pembagian komunitas menjadi mereka yang mengembangkan
runtime dari mesin virtual / kompiler atau mesin virtual itu sendiri dan menjadi pengembang aplikasi. Ini jelas terlihat dalam kode kelas JDK standar. Seringkali penulis JDK menggunakan API yang berbeda. Secara potensial, ini berarti bahwa kita tidak dapat mencapai kinerja puncak. Secara umum, saya percaya bahwa menggunakan API yang sama untuk menulis pustaka standar dan kode aplikasi adalah indikator yang sangat baik untuk kematangan platform.
Satu hal lagi
Saya pikir sangat penting bagi semua pengembang untuk mengetahui bagaimana, jika bukan seluruh tumpukan, maka setidaknya setengahnya berfungsi: kode Java, kode byte, internal runtime dan assembler mesin virtual, perangkat keras, OS, jaringan. Ini memungkinkan Anda melihat masalah secara lebih luas.
Kinerja juga layak disebut. Sangat penting untuk tidak fokus pada rata-rata dan selalu melihat pada median dan persentil tinggi (pengukuran terburuk 10/100/1000 / ...).
Saya akan membicarakan semua ini di
pertemuan Java User Group pada 30 Mei di St. Petersburg. Bertemu dengan Sergei Melnikov, itu hanya saya)) Anda dapat mendaftar di
sini .
Apa yang akan kita bicarakan?- Tentang membuat profil dan menggunakan Linux standar dan profil perf: cara hidup bersama mereka, apa yang mereka ukur dan bagaimana menginterpretasikan hasil mereka. Ini akan menjadi pengantar profil umum, dengan tips, peretasan kehidupan, cara memeras segala kemungkinan dari profiler sehingga profil mereka dengan akurasi dan frekuensi maksimum.
- Tentang fitur peralatan untuk mendapatkan profil yang lebih rinci dan melihat profil peristiwa langka. Misalnya, ketika kode Anda berjalan 10 kali lebih lambat setiap kali keseratus. Tidak ada profiler yang akan menceritakan hal ini. Kami akan menulis profiler kecil kami menggunakan mekanisme kernel Linux standar dan mencoba melihat profil beberapa peristiwa langka.
Datang ke pertemuan, itu akan menjadi malam yang menyenangkan, akan ada banyak cerita menarik tentang platform kami dan tentang bahasa favorit kami.
Sampai jumpa;)