Belajar Swoole - Arsitektur & Model Concurrency
Membedah arsitektur internal Swoole: proses Master dan Manager yang mengelola sekumpulan worker dan task processes, event loop berbasis reactor, penjadwalan coroutine, serta memory model per-worker yang menjaga keamanan state antar proses.
#Pendahuluan
Setelah di episode 1 kita memahami mengapa Swoole ada — lahir dari keterbatasan PHP-FPM dan kemenangan benchmark di 2026 — pada episode kali ini kita membedah bagaimana Swoole bekerja di balik layar. Ini adalah fondasi paling penting dalam series: tanpa memahami arsitekturnya, semua episode praktik berikutnya hanya akan menjadi "meniru kode tanpa mengerti".
Mengapa episode ini penting? Karena konfigurasi Swoole (worker_num, dispatch_mode, task_worker_num, dst.) hanyalah nama-nama pada konsep arsitektur yang sama. Ketika kalian paham peran Master, worker, dan event loop, kalian akan membaca setiap config seperti membaca peta, bukan teka-teki.
#Gambaran Arsitektur
Swoole adalah multi-process server yang polanya mirip Nginx: satu proses kontrol yang tidak pernah memproses request, dan sekumpulan proses pekerja yang melayaninya:
Peran tiap komponen:
| Komponen | Tugas |
|---|---|
| Master | Proses utama yang paling awal lahir; mengelola signal, fork Manager. Tidak pernah memproses request. |
| Manager | "Orkestrator": me-launch, memantau, dan me-restart worker/task worker yang mati. |
| Worker | Mengeksekusi kode bisnis kalian (on('Request'), on('Message'), dst). |
| Task Worker | Menangani pekerjaan berat yang dikirim lewat task() — dibahas di episode 11. |
| Event Loop (Reactor) | Inti concurrency: mendengarkan socket, membaca data, dan menyalurkan event ke worker. |
#Mengapa Multi-Process, Bukan Multi-Thread?
Pilihan ini bukan kebetulan. PHP tidak dirancang untuk multi-threading — interpreter, ekstensi, dan library lama pada umumnya tidak thread-safe. Dengan model multi-process, setiap worker adalah interpreter PHP yang berdiri sendiri. Jika satu worker crash karena bug atau exit(), worker lain tidak terpengaruh; Manager tinggal me-restart yang mati.
Analoginya: PHP-FPM juga multi-process, tetapi setiap proses hanya melayani satu request lalu mati. Di Swoole, setiap worker melayani ribuan request secara berurutan dan tetap hidup — di sinilah letak efisiensinya. Proses mati hanya saat direcycle (diatur max_request, episode 20).
#Event Loop dan Reactor
Jantung Swoole adalah event loop berbasis epoll (Linux) atau kqueue (macOS). Alur penanganan koneksi kira-kira begini:
- Socket mendengarkan koneksi masuk — event connect dikirim.
- Data tiba di socket — event read memicu pembacaan.
- Request lengkap terpasang — worker mengeksekusi handler kalian.
- Response ditulis — event write menyalurkan data kembali ke client.
Semua langkah ini tidak memblokir. Ketika sebuah coroutine menunggu I/O (misal query database), event loop berpindah mengerjakan coroutine lain yang siap, lalu kembali saat data database tiba. Inilah yang membuat satu worker mampu melayani ribuan koneksi aktif secara bersamaan.
#Coroutine: Kode Sinkron, Eksekusi Async
Coroutine adalah titik paling khas Swoole. Kalian menulis kode yang terlihat berurutan dan sinkron:
$resp = $httpClient->get('/api/users');
$data = json_decode($resp->getBody(), true);Sekilas seperti kode PHP biasa — dan justru itulah tujuannya. Di belakang layar, Swoole menyimpan context setiap coroutine (tumpukan stack-nya), lalu menunda eksekusi saat menunggu I/O dan melanjutkannya saat data siap. Tidak ada callback, tidak ada promise chaining.
Perbedaan mental modelnya:
| Model | Cara kerja | Contoh |
|---|---|---|
| Blocking (FPM) | Satu operasi selesai baru operasi berikutnya | file_get_contents |
| Callback (async klasik) | Kode berantakan bersarang | client->on('data', fn => ...) |
| Coroutine (Swoole) | Tulis sinkron, jalankan non-blocking | $client->get() di dalam coroutine |
#Scheduler: Siapa yang Menjalankan Coroutine?
Penjadwalan coroutine dikendalikan oleh coroutine scheduler di dalam setiap worker. Poin pentingnya:
- Coroutine hanya berpindah eksekusi di titik yang aman (yield point) — biasanya saat I/O atau pemanggilan
Coroutine::suspend(). - Preemptive terhadap waktu hanya didukung OpenSwoole 26.x via Fiber; di Swoole klasik, satu coroutine yang sibuk CPU terus menerus bisa "kelaparan" coroutine lain dalam satu worker.
- Coroutine tidak bisa dipakai di luar context coroutine untuk operasi yang butuh hook — kita bahas detail di episode 7.
Konsekuensi praktisnya: kode CPU-heavy (loop panjang, kompresi) sebaiknya tidak berjalan di worker biasa agar tidak memblokir worker — itulah gunanya task worker (episode 11).
#Memory Model: State Per-Worker
Karena multi-process, memory antar worker tidak dibagi. Konsekuensinya:
| Hal | Behavior |
|---|---|
| Variabel PHP | Terisolasi per worker; tidak bisa diakses worker lain |
| State persist antar request | Bisa disimpan di properti object yang hidup sepanjang worker |
| State shared antar worker | Wajib lewat Swoole\Table (shared memory), Redis, atau Atomic |
| Concurrency dalam satu worker | Aman — request diproses satu per satu |
Ini adalah sumber kebingungan paling umum developer Swoole pemula: menambah counter $count++ di worker ternyata tidak terlihat di worker lain. Untuk counter global, gunakan Swoole\Atomic — kita bahas di episode 12.
Warning
Jangan pernah menyimpan state bisnis penting hanya di variabel PHP biasa bila aplikasi kalian memakai lebih dari satu worker. Karena request bisa masuk ke worker mana pun (bergantung dispatch_mode), state harus hidup di layer yang dibagi: Table, Atomic, Redis, atau database. Ini kesalahan arsitektur nomor satu di aplikasi Swoole produksi.
#Event vs Callback: Model Pemrograman
Pengembangan Swoole berbasis event callback. Server kalian mendaftarkan handler untuk event tertentu:
| Event | Dipicu saat | Episode |
|---|---|---|
on('Start') | Server mulai berjalan | 4 |
on('WorkerStart') | Sebuah worker di-launch | 4 |
on('Request') | Request HTTP diterima | 4-5 |
on('Open') / on('Message') / on('Close') | Koneksi WebSocket | 6 |
on('Task') / on('Finish') | Task diterima / selesai | 11 |
on('PipeMessage') | Pesan antar worker via sendMessage() | 10 |
Model ini konsisten di semua tipe server Swoole — kalian hanya mengganti Swoole\Server dengan Swoole\Http\Server atau Swoole\WebSocket\Server, dan event callback-nya menyesuaikan.
#Penutup
Pada episode 2 ini, kalian telah memahami arsitektur inti Swoole.
Inti yang harus dibawa pulang:
- Swoole = multi-process: Master + Manager + worker + task worker, pola ala Nginx.
- Event loop (epoll/kqueue) membuat satu worker mampu melayani ribuan koneksi tanpa memblokir.
- Coroutine menyatukan kecepatan async dengan kenyamanan kode sinkron.
- Memory terisolasi per worker; state lintas worker wajib lewat Table/Atomic/Redis.
- Konfigurasi
worker_num,task_worker_num, dandispatch_modeadalah parameter dari arsitektur ini.
Di episode 3 selanjutnya, kita masuk ke tangan: instalasi & konfigurasi Swoole — dari pecl install, build options saat kompilasi, hingga setelan php.ini yang wajib kalian ketahui. Sampai jumpa di episode 3!