Pengumuman mitap yang dengan lancar berubah menjadi tempat minum BeerPHP (di Moskow dan online)

Hai, pada bulan Agustus kami akan mengadakan pertemuan di Moskow dengan pembicara dari kota-kota lain, pertemuan BeerPHP dan siaran bagian resmi untuk semua orang yang tidak dapat bergabung.

Hari ini kami mulai memperkenalkan pembicara . Sergey Zhuk akan datang ke pertemuan dari Bryansk - tidak ada pesta di kotanya, dan dia memiliki sesuatu untuk diceritakan tentang PHP asinkron: dia menulis buku tentang ini, serangkaian artikel dan banyak lagi. Di bawah ini adalah transkrip podcast terbaru tentang ini, tautan ke mendengarkan dan melihat rilis, serta detail tentang mitap itu sendiri.



Pyotr Myazin alias PQR : Hari ini, saya berhubungan dengan salah satu pakar utama ReactPHP. Sergey, saya baru-baru ini mengunjungi reactphp.org dan menemukan Anda di halaman utama. Anda banyak menulis tentang topik ini, Anda bahkan memiliki saluran sendiri dengan instruksi video. Katakan bagaimana Anda sampai pada ini, apa yang membuat Anda ketagihan di ReactPHP?

Bahkan, Anda menemukan kembali bahasa yang telah Anda tulis selama bertahun-tahun

Sergey aka seregazhuk : Dua tahun lalu, pada pekerjaan sebelumnya, perlu untuk menulis sebuah skrip yang akan terus-menerus menelepon pelanggan dan bekerja dengan sangat cepat. Tugas harus diselesaikan "kemarin", hanya pengembang PHP yang ada di tim - tidak ada waktu untuk tumpukan baru, Anda tahu. Tapi ternyata semua orang mendengar sesuatu tentang ReactPHP. Dia memposisikan dirinya sebagai siap produksi, semuanya sangat mudah: kami baru saja menginstal perusahaan melalui komposer, dan dimungkinkan untuk menulis kode asinkron. Sebagai hasilnya, mereka menulis solusi di atasnya, meluncurkannya, semua orang puas.

Saya menyadari bahwa kami memiliki alat - tetapi hampir tidak ada artikel, contoh praktis seperti "Kami memiliki masalah seperti itu, kami menyelesaikannya seperti ini" baik dalam bahasa Rusia maupun bahasa Inggris. Akibatnya, saya menulis beberapa artikel di blog saya, mendapat umpan balik positif, dan itu saja - entah bagaimana itu menyeret saya. Kami terbiasa dengan model Permintaan-Respons, tetapi ada baiknya memuatnya ke dalam kode asinkron, dan Anda akan segera bertanya: "Bagaimana mungkin?"

Peter: Mari kita bicara lagi, masalah apa yang dipecahkan oleh kode asinkron untuk kita, dan mengapa ReactPHP dibutuhkan secara khusus?

Sergey: Hampir setiap aplikasi memiliki panggilan API, atau interaksi dengan sistem file, atau permintaan basis data. Ketika kami menunggu jawaban dari mereka, prosesor kami tidak digunakan - alih-alih melakukan sesuatu yang bermanfaat. Anda tidak dapat menunggu jawaban, tetapi mulai operasi non-pemblokiran dan lanjutkan. Timbul pertanyaan: "Jika kita mendapatkan ReactPHP di mana-mana untuk I / O, apakah aplikasi kita akan berkali-kali lebih cepat?"

Sayangnya, Anda tidak bisa hanya mengambil dan menulis ulang aplikasi kami menjadi yang tidak sinkron

Sergey: Saya akan berpikir tentang menggunakan ReactPHP dalam kasus di mana kinerja sangat penting, dan I / O adalah botlock kami yang memblokir semuanya. Selain itu, saya akan merekomendasikan untuk tidak mentransfer seluruh aplikasi ke rel asinkron, yaitu untuk menulis ulang botlock khusus ini. Biasanya, irisan asinkron jauh lebih mudah dimasukkan ke dalam kode pemblokiran tradisional daripada mencoba menulis ulang seluruh aplikasi.

Peter: Ok, tapi mengapa kita tidak memulai beberapa proses PHP saja? Yang ini tidak digunakan, tetapi yang berikutnya sibuk.

Sergey: Dan bagaimana kita mengoordinasikan hasilnya? Misalkan kita perlu mendapatkan data dari tiga sumber, kita membuat panggilan ke tiga API, lalu kita menyusun hasilnya dan memberikannya kepada pengguna. Jika kita membuat tiga aliran terpisah, maka masalah koordinasi hasilnya akan muncul.

Dengan pendekatan asinkron, kami hanya menjalankannya, sehingga secara paralel, maka kami mendapatkan hasilnya dan memprosesnya. Dengan utas, Anda harus entah bagaimana mengoordinasikan bola ini, yaitu, akan ada masalah dengan negara. Ini tampaknya lebih rumit daripada pendekatan asinkron.

Peter: Saya mengerti. Saya memiliki pemikiran ini di kepala saya: jika kita ingin meningkatkan jumlah pengguna. diproses per detik, bagaimana seluruh tumpukan aplikasi dari Symfony akan diluncurkan dalam versi asinkron dan memproses jumlah koneksi yang lebih besar?

Sergey: Saya tidak akan melakukan itu. Seringkali, aplikasi tidak melambat sepenuhnya. Jika pertanyaan tentang kinerja muncul, kemungkinan besar ada beberapa hambatan di dalam, yang juga kemungkinan besar mengakibatkan I / O lambat. Dan sekarang saya akan menerjemahkan hambatan ini ke ReactPHP.

Itu akan terlihat seperti program asinkron kecil di dalam kode pemblokiran yang biasa: misalnya, kami memanggil tiga permintaan secara paralel, memprosesnya dan mengirim respons kepada pengguna, dan total waktu eksekusi akan sama dengan waktu permintaan paling lambat. Jika dalam hal pendekatan tradisional, kami akan menunggu permintaan pertama, yang kedua dan ketiga. Tetapi aplikasi tidak menjadi sinkron dari ini.

Dan jika kita membandingkan semuanya dengan NodeJS dan lainnya?

Peter: Dan jika kita membandingkan semuanya dengan NodeJS, katakanlah, atau Pergi, benar-benar ada sinkronisasi melalui seluruh aplikasi. Semua permintaan ke database, ke sistem file - semuanya ada di dalam sinkron. Apakah ini berarti, pada prinsipnya, jika semuanya ditulis dalam bentuk asinkron, apakah ada untungnya?

Sergey: Akan menguntungkan jika masalah awalnya adalah I / O. Maka ya, kami akan menyelesaikannya. Kode kami akan seefisien mungkin, dapat memproses jumlah tugas maksimum dan bukannya menganggur dan menunggu hasil ini diproses. Tetapi jika pada awalnya masalahnya bukan di I / O, maka menulis semuanya secara serempak, kita tidak mungkin memenangkan apa pun, dan kita bisa mendapatkan kode kompleks yang akan sulit dibaca dan dipelihara.

Peter: Kembali ke PHP. Jadi, kami memiliki ReactPHP, dan dari analog Swoole, Amp dan Ext-async yang terkenal. Dan katakan kepada saya sebagai perbandingan, apa perbedaan antara proyek-proyek ini, dan seberapa bagus ReactPHP, apakah cepat dan apakah ada kekurangan dibandingkan dengan Swoole yang sama?

Sergey: Dari ketiganya, jujur ​​saja, saya hanya menguji Amp, dan karena itu, seperti ReactPHP, didukung langsung di luar kotak. Artinya, kami menempatkan komponen yang diperlukan melalui komposer dan Anda selesai. Dan di sini saya tidak terlalu suka cerita dengan ekstensi. Karena jika kita dibiarkan sendiri dengan PHP dan asinkron, maka, menurut saya, lebih masuk akal untuk menggunakan bahasa dan hal-hal asli - dan jika kita menggunakan ekstensi tambahan, maka di sini bukan PHP asinkron, tetapi ekstensi asinkron untuk PHP.

Bagaimana ReactPHP Benar-Benar Siap Produksi?

Peter: "Dukungan jangka panjang" ditulis di situs web mereka. Artinya, semacam dukungan jangka panjang, tanpa perubahan kritis pada API. Benarkah begitu? Apakah semuanya cukup tinggi?

Sergey: Ya. Proyek ReactPHP sendiri sudah cukup tua. Dia telah bekerja sejak tahun kedua belas, dia berusia 7 tahun. Dia sudah memiliki waktu siap produksi yang cukup. Dan ya, apalagi, inilah dukungan jangka panjang untuk komponen utama selama 2 tahun. Artinya, Anda dapat dengan aman diikat ke komponen-komponen ini, menerima perbaikan, pembaruan dan tidak khawatir tentang kompatibilitas ke belakang. Selama dua tahun mereka berusaha mempertahankan versinya, tidak ada yang akan rusak. Ini, saya pikir, benar-benar keren, ini adalah langkah maju yang besar. Sejauh yang saya ingat, sampai saat ini, Amp membahas beberapa komponennya, mereka tidak sepenuhnya memutuskan antarmuka dan API publik mereka.

Peter: Di mana Anda merekomendasikan untuk mulai belajar ReactPHP? Selain dokumentasi resmi dan tutorial video Anda, tentu saja. Di mana semua komunitas, apakah ada obrolan telegram atau obrolan obrolan, forum?

Sergey: Sayangnya, saya tidak tahu komunitas langsung seperti itu. Ada akun Twitter yang cukup aktif: di sana Anda dapat bertanya, bertanya, dan tertarik. Dan para penambang merespons dengan sangat cepat - Anda dapat secara pribadi menulis kepada mereka di Twitter. Saya melakukannya, meminta mereka untuk beberapa hal.



Peter: Baiklah, terima kasih atas cerita yang begitu mendetail tentang ReactPHP - dan dalam hal ini saya akan mengumumkan Pertemuan Panda , yang akan diadakan pada 22 Agustus di Moskow di kantor Skyeng. Anda akan tampil di sana, bukan?

Sergey: Ya, benar. Datang dan ngobrol.

Peter: Juga akan ada laporan tentang Desain Berbasis Domain, yang juga merupakan topik menarik yang menarik dalam konteks PHP, [dan beberapa lagi yang lain telah ditambahkan] dan, seperti yang dikatakan panitia, akan ada beberapa pesta setelah pesta.

Barang:

• Audio lengkap dan versi podcast YouTube
• Tautan ke broadcast mitap untuk mereka yang tidak bisa datang
• Rincian tentang pesta sesudahnya di telegram BeerPHP Moscow