RubyRussia 2019. Julian Pokrovsky: cara mengoptimalkan monolith

Terlepas dari sejumlah besar materi tentang topik optimasi monolit, saya sering ingin menghindari mempelajari masalah ini secara mendalam dan mencoba menebak bagaimana membuat aplikasi lebih cepat atau lebih ringkas. Berita baiknya: prinsip Pareto bekerja di sini. Pada konferensi RubyRusia pada 28 September, Julian Pokrovsky akan berbicara tentang teknik yang diperlukan. Beberapa penggoda akan berada dalam wawancara ini dengan Julian dan Grigory Petrov .



Apa yang Anda lakukan di dunia IT, Ruby, minat, keahlian Anda?

Saya bekerja di Cupill. Dalam proyek itu, saya menulis di Ruby dan di backend Rust untuk mencari, memesan, dan membeli tiket pesawat. Saya tertarik dengan berbagai hal yang terjadi di TI: mulai dari kompiler hingga sistem terdistribusi. Tidak terlalu tertarik dengan pembelajaran mesin dan front-end, tapi mungkin suatu hari nanti saya akan sampai di sana juga.

Ceritakan tentang apa laporan Anda?

Saya akan menceritakan tentang pengalaman kami dalam mengoptimalkan monolit berusia 8 tahun dan menunjukkan bahwa itu sangat sederhana dan bermanfaat bagi semua orang. Dan ada peluang untuk mengalokasikan waktu untuk ini dalam sprint. Anda bisa mendapatkan peningkatan kinerja dengan melihat hanya beberapa trik dan alat sederhana yang tidak memerlukan Rails dan cocok tidak hanya untuk aplikasi web. Saya akan memberi tahu Anda tentang materi yang dipandu saat memecahkan masalah kami. Mari kita lihat stackprof, rbspy, heapy, dan juga mengapa perubahan sepele pada pengaturan sistem operasi, mengubah pengalokasi, dapat membawa manfaat luar biasa. Dan mengapa buruk untuk menerapkan saran dari Internet tanpa melakukan pengukuran pada aplikasi Anda.

Ada legenda urban sehingga jika kita membandingkan bahasa Big Four (Ruby, Python, JavaScript dan PHP), maka pertama-tama kita memiliki JS, karena ada menunggu dan jit, dalam PHP kedua, kemudian Python, dan Ruby mengambil 4 terhormat apa yang Anda katakan, begitu?

Saya tidak cenderung menyangkal bahwa Ruby tidak bekerja dengan baik pada banyak tolok ukur. Tetapi jelas tidak benar untuk mengatakan bahwa dalam situasi apa pun dia akan berada di tempat terakhir. Lebih luas lagi, Ruby adalah standar bahasa. Kita dapat berbicara tentang TruffleRuby, tentang JRuby, tentang MRI, tentang masalah kinerja. Ini adalah hal yang sangat individual. Itu semua tergantung pada bagaimana Anda menulis kode dan apa yang ingin Anda dapatkan. Dalam beberapa kasus, Ruby akan lebih cepat daripada siapa pun, dalam beberapa Python, bukan tanpa alasan itu populer dalam ilmu data, terkadang JavaScript akan menjadi yang tercepat.

Sejauh mana ekosistem Ruby sekarang menawarkan cara-cara asli yang cepat untuk menyelesaikan masalah populer?

Saya dapat menafsirkan pertanyaan secara berbeda. Anda dapat berbicara tentang apa yang terjadi dengan ekstensi-C di Ruby sekarang. Jika kita mempersempit pertanyaan ini, maka kita semua tahu: OJ untuk serialisasi JSON, Driver PostgreSQL, Driver Ruby untuk MySQL dan banyak hal lain ditulis dalam C. Pertanyaannya adalah seberapa baik atau buruknya bagi saya secara pribadi. Agar kompiler jit, yang mungkin merupakan masa depan Ruby, untuk mengoptimalkan kode dengan baik, kita perlu menulis lebih banyak di Ruby dan menggunakan lebih sedikit luasan. Sehingga kompiler dapat melakukan ini. TruffleRuby memiliki pendekatan berbeda untuk ini. Sejauh yang saya ingat, ini memungkinkan Anda untuk melakukan optimasi antara berbagai bahasa, oleh karena itu disebut polyglot vm. Sekali lagi, seberapa sukses dia melakukan ini, saya tidak siap untuk mengatakannya. Dan TruffleRuby sendiri masih merupakan proyek yang cukup muda.

Kemajuan apa di dunia Ruby yang ada untuk pemrograman asinkron?

Menurut pendapat saya, tidak ada gerakan massa baru-baru ini menuju Ruby asinkron telah terjadi. Ada beberapa proyek terpisah: baik EventMachine terbukti dan proyek Sam Williams, async , atau lebih tepatnya seluruh kelompok proyek di mana implementasi asinkron baru dibuat berdasarkan nio4r , yang lebih sederhana daripada EventMachine atau Celluloid. Namun secara umum, sejarah, meski tidak diam, melainkan berjalan dalam lingkaran kecil. Dan sejauh ini tidak ada yang melampaui itu. Mari kita lihat apa yang terjadi selanjutnya.

Saya masih melihat banyak penggunaan berbasis-ruby bersamaan. Ini bukan pilihan yang buruk untuk bahasa dengan runtime yang cukup produktif - gunakan stream yang melepaskan GVL (kunci global) dan memungkinkan Anda untuk membuat permintaan HTTP paralel atau beberapa operasi I / O lainnya pada saat yang sama. Mungkin serat di masa depan akan lebih populer. Mereka sekarang membentuk dasar perpustakaan dari kelompok efek kering - kering. Ini hanya memungkinkan Anda untuk melakukan beberapa operasi paralel berdasarkan serat. Tidak sinkron, tetapi tidak sepenuhnya asinkron - sudah setengah asinkron.

Matsumoto-san, penulis Ruby, terbang ke konferensi. Menurut Anda, apa yang menarik bagi Anda untuk berdiskusi dengannya tentang secangkir kopi atau segelas sake di pesta sesudahnya?

Saya sudah melihat Matsumoto di Moskow pada tahun 2016. Saya ingat, dia kemudian mengatakan bahwa jika konferensi terus disebut RailsClub dia tidak akan datang lagi.

Ya, dan namanya diubah RubyRussia, ini adalah nama yang lebih luas. Dan dia mengunjungi kita lagi.

Saya kemudian berpikir siapa yang akan menang, dia atau RailsClub. Matsumoto dikalahkan. Saya akan bertanya bagaimana dia berhasil mengajukan pertanyaan sedemikian rupa sehingga mereka menamai ulang acara Ruby terbesar di Rusia.

Saya pikir Anda akan memiliki setiap kesempatan untuk mengajukan pertanyaan ini secara pribadi. Apa masa depan Ruby? Apa yang kurang dalam bahasa, ekosistem?

Memprediksi nasib suatu bahasa pemrograman adalah tugas yang tidak memiliki rasa terima kasih, karena sejauh ini belum ada yang menebak bagaimana perkembangan acara untuk bahasa apa pun. Saya bisa saja salah, tetapi Ruby bukan pilihan paling populer untuk proyek-proyek baru saat ini. Banyak yang telah mendengar "Ruby sudah mati, tetapi Rails sudah usang": lambat, tidak sinkron, tidak paralel dan memiliki banyak masalah. Apakah ini mempengaruhi jumlah proyek Ruby baru? Menurut saya, pasti iya. Mereka menjadi lebih kecil dan akan menjadi lebih kecil. Tapi proyek lama tetap ada. Menurut pendapat saya, dengan cara ini Ruby membutuhkan alat untuk mendukung aplikasi yang kompleks dan masif. Dalam situasi seperti itu, merupakan ide bagus untuk melihat penambahan seperti sistem tipe. Banyak orang lebih suka mendukung aplikasi besar dan mengembangkannya, seperti yang dapat kita lihat dengan JavaScript dengan Flow dan TypeScript, untuk mengetik, yang membuat refactoring dan pemantauan situasi dalam proyek yang kompleks menjadi sedikit lebih mudah. Mungkin Anda perlu membuat ekosistem perpustakaan yang lebih kaya yang perlu Anda gunakan secara mandiri, seperti dry-rb. Di mana seseorang dapat memilih apa yang perlu divalidasi, apa yang membangun efek di beberapa subsistem. Mungkin dia membutuhkan wadah injeksi ketergantungan yang memecahkan masalah tertentu. Ekosistem harus bergerak ke arah ini. Dalam arah pengembangan usaha dan dukungan sistem yang besar dan kompleks.

Diskusikan di RubyRussia!

Datang dan Anda, pendaftaran masih terbuka.

Tidak hanya akan ada laporan, tetapi juga stan perusahaan keren:

Penyelenggara - Evrone
Mitra Umum - Toptal
Mitra Emas - Gett
Mitra Perak - Valarm , JetBrains , Bookmate dan Cashwagon
Mitra Perunggu - InSales