RFC PHP yang mendefinisikan Polling API bawaan telah disetujui dan digabungkan ke dalam branch master bahasa tersebut, memberikan pengembang cara yang cepat di tingkat OS untuk melakukan polling pada file descriptor. Dipadukan dengan Fibers yang baru saja ditambahkan, PHP kini memiliki fondasi bawaan yang efisien untuk kode asinkron—sebuah celah yang selama ini memaksa pustaka (library) untuk merakit solusi sementara mereka sendiri.

Fibers dan event loop, dipisahkan

Fibers adalah primitif alur kontrol tingkat rendah. Mereka memungkinkan sebuah fungsi untuk menangguhkan eksekusinya pada titik tertentu dan kemudian melanjutkannya tepat di tempat ia berhenti. Yang terpenting, sebuah fiber tidak mengetahui apa pun tentang socket, timer, atau sumber I/O lainnya; ia hanya berhenti sejenak dan memulai ulang sesuai permintaan.

Event loop adalah penjadwal (scheduler) yang memutuskan kapan fiber yang tertangguh harus dilanjutkan. Dalam tumpukan (stack) asinkron yang umum, loop memantau sekumpulan file descriptor, menunggu hingga mereka dapat dibaca atau ditulis, lalu membangunkan fiber yang sesuai.

Sebelumnya PHP sudah memiliki Fibers tetapi kekurangan mekanisme bawaan untuk menanyakan kepada sistem operasi descriptor mana yang sudah siap. Hasilnya adalah ketergantungan pada stream_select() atau ekstensi eksternal, dan setiap pustaka asinkron akhirnya menulis backend mereka sendiri untuk epoll di Linux, kqueue di BSD, IOCP di Windows, dll.

Polling API yang baru mengisi celah tersebut. API ini menyediakan wrapper tipis di sekitar fasilitas polling OS (epoll pada Linux, kqueue pada BSD/macOS, dll.). API ini tidak menggantikan Fibers; ia hanya memberikan kecepatan dan skalabilitas yang dibutuhkan oleh event loop.

Mengapa perubahan ini penting bagi ReactPHP, Amp, dan kawan-kawan

ReactPHP dan Amp v3 telah membangun lapisan abstraksi mereka sendiri di atas mekanisme polling OS. Lapisan-lapisan tersebut berisi beberapa jalur kode, yang masing-masing disesuaikan untuk platform tertentu, dan harus tetap sinkron dengan perubahan kernel. Dengan Polling API bawaan, pustaka-pustaka tersebut dapat membuang sebagian besar infrastruktur internal tersebut dan mengandalkan satu panggilan tunggal yang disediakan oleh core.

  • Pemeliharaan – Lebih sedikit cabang spesifik platform berarti lebih sedikit bug dan area permukaan yang lebih kecil untuk tinjauan keamanan.
  • Performa – Panggilan bawaan berbicara langsung ke epoll/kqueue.
  • Portabilitas – Kode yang berjalan pada PHP “vanilla” kini mendapatkan performa dasar yang sama di semua sistem operasi yang didukung, tanpa perlu ekstensi opsional.

Sebaliknya, Swoole tetap menjadi pengganti runtime penuh yang menyertakan event loop dan sistem coroutine sendiri. Polling API tidak memengaruhi trade-off Swoole; pengembang yang membutuhkan latensi ultra-rendah atau manajemen memori khusus akan tetap menganggapnya sebagai opsi terpisah.

Benchmark singkat menunjukkan hasilnya

Sebuah scheduler minimal mengambil beberapa URL melalui raw socket, menggunakan satu Io\Poll\Context untuk mengelola beberapa fiber. Dua pengamatan muncul:

  1. Kecepatan – Menambahkan lebih banyak permintaan konkuren tidak meningkatkan total waktu yang dihabiskan; batch permintaan selesai secepat permintaan tunggal yang paling lambat. Dengan kata lain, overhead konkurensi secara efektif adalah nol.
  2. Biaya CPU – Dengan stream_select(), penggunaan CPU meningkat secara nyata seiring bertambahnya jumlah stream, karena fungsi tersebut harus melakukan iterasi pada setiap descriptor di setiap panggilan. Biaya Polling API tetap stabil dari tiga stream hingga tiga puluh, berkat kemampuan kernel untuk memantau banyak descriptor dalam satu panggilan sistem tunggal.

Apa yang harus dilakukan pengembang sekarang

  • Adopsi Amp v3 jika Anda lebih menyukai gaya fiber-native yang selaras langsung dengan API baru. Antarmuka publiknya sudah memetakan ke poller yang mendasarinya, sehingga Anda mendapatkan manfaatnya tanpa harus menulis ulang kode Anda.
  • Tetap gunakan ReactPHP jika Anda menyukai kontrol eksplisit atas siklus hidup loop.
  • Hindari scheduler kustom untuk beban kerja produksi. Jangan menulis scheduler Anda sendiri untuk produksi.