Flaky test pada event loop Linux menandakan bahwa perbedaan kondisi sistem atau peralatan polling memengaruhi hasil akhir. Untuk mengatasi ini, fokus utama adalah memastikan bahwa pengujian memverifikasi mekanisme polling (epoll atau io_uring) secara eksplisit, dan bahwa setiap regresi dalam event loop mudah dideteksi melalui observabilitas dan pengujian terstruktur.

Pembandingan reliabilitas Epoll vs io_uring harus dilakukan dalam konteks bagaimana masing-masing berperilaku di bawah beban tinggi, latency jitter, dan fail-over. Kita akan melihat strategi pengujian, alur verifikasi, metrik yang harus diukur, serta praktik preventif untuk memastikan transisi event loop tetap stabil.

Memahami Perbandingan Reliabilitas Epoll vs io_uring

Berdasarkan tren yang dijabarkan di artikel sibexi.co/posts/epoll-vs-io_uring/, io_uring menawarkan latency lebih rendah dan integrasi langsung dengan kernel non-blocking, tetapi epoll tetap menjadi landasan yang sangat matang. Flaky test lebih mungkin terjadi saat kode mengandalkan asumsi waktu ataupun ketika event-loop berganti tanpa pengujian eksplisit. Keandalan harus ditakar lewat pengujian multi-skenario yang mengemulasikan masalah nyata seperti beban burst, penutupan descriptor mendadak, dan timeouts.

Untuk pemilihan: gunakan epoll jika stabilitas fungsi tradisional dan backward compatibility adalah prioritas utama; gunakan io_uring saat throughput tinggi dan kebutuhan I/O asynchronous modern mendorong kompleksitas pencarian solusi alternatif. Tetap saja, flaky test bisa muncul pada keduanya jika tidak ada verifikasi event polling yang sistematis.

Strategi Pengujian untuk Mendeteksi Flaky Test

Jenis Pengujian Terstruktur

  • Integrasi – Jalankan suite yang mengekspos event-loop ke layer middleware atau driver jaringan; pastikan event readiness (read/write) diverifikasi secara eksplisit dengan epoll_wait/io_uring_wait saat fungsionalitas dipicu.
  • Load – Gunakan beban multi-threaded dengan descriptor bertumbukan dan latensi tinggi, uji handler yang sama di bawah epoll dan io_uring untuk mengungkap race condition.
  • Regression – Jalankan suite hampir serupa pada setiap commit yang mengubah konfigurasi polling atau dependency kernel, termasuk kombinasi flag seperti EPOLLONESHOT atau IORING_SETUP_SQPOLL.

Setiap jenis pengujian harus menetapkan baseline hasil yang stabil, misalnya jumlah event yang diproses atau urutan callback. Flaky test dapat dideteksi dengan membandingkan hasil keseluruhan dari beberapa run berurutan.

Alur Verifikasi Ideal

  1. Konfigurasikan pipeline untuk memilih event loop via env var, contoh: EVENT_LOOP=epoll atau EVENT_LOOP=io_uring.
  2. Jalankan suite integrasi dengan logging event readiness dan waktu eksekusi handler.
  3. Bandingkan hasil run epoll vs io_uring: perbedaan signifikan (misalnya handler tidak dipanggil) menandakan flaky test atau issue reliabilitas.
  4. Catat trace kernel dan stack trace dengan perf/strace bila terjadi perbedaan.

Alur ini bisa diotomasi dengan CI yang mengeksekusi host docker image berbeda konfigurasi kernel driver untuk menjalankan event loop yang relevan.

Metrik Observabilitas

  • Latency per event – distribusi waktu sejak readiness sampai handler dieksekusi.
  • Retry dan re-register count – berapa kali descriptor diregistrasi ulang karena missed event.
  • Pending queue length – ukuran antrean event yang menunggu diproses.
  • Error kode kernel – misalnya EAGAIN yang tiba secara tak terduga menandakan race.
  • Trace stack handler – untuk melihat apakah proses event loop berbeda antara epoll dan io_uring.

Pengumpulan metrik ini dapat menggunakan eBPF atau instrumentation middleware agar tidak terlalu mengganggu jalannya event loop.

Implementasi Praktis dan Skenario Nyata

Skenario nyata: sistem proxy TCP dengan ribuan koneksi. Suatu ketika, perubahan pada scheduler thread menyebabkan salah satu socket tidak menerima event lagi saat menggunakan io_uring. Untuk mendeteksi regression, kita membangun pipeline berikut:

#!/bin/bash
set -euo pipefail
for loop in epoll io_uring; do
  EVENT_LOOP=$loop ./run_proxy_tests.sh --suite=event-loop
  sleep 2
  ./collect_metrics.sh --target=$loop
done

Script ini menjalankan suite yang menguji concurrency dengan latensi tinggi dan mengumpulkan metrik readiness. Jika run io_uring tiba-tiba menunjukkan peningkatan re-register, berarti ada flaky test atau bug yang perlu ditelaah (misalnya queue overflow ketika SQPOLL aktif).

Untuk debugging mendalam, gunakan sudo perf record -e io_uring:io_uring_submit atau strace -f -e trace=epoll_wait untuk melihat perbedaan perilaku dalam kasus failure.

Trade-off dan Praktik Preventif

Testing epoll cenderung lebih mudah karena sudah lama tersedia dan lebih deterministik. io_uring memberikan performa superior, tetapi membutuhkan perhatian lebih pada buffer management dan custom completion handling. Flaky test pada io_uring sering berasal dari buffer lifetime yang tidak jelas atau submission queue yang penuh.

Untuk mencegah regression, lakukan:

  • Mata rantai merge request: setiap perubahan yang memengaruhi scheduler atau thread affinity harus melewati suite epoll dan io_uring.
  • Gunakan fitur claimable buffers seperti IORING_SQE_FIXED_FILE dengan hati-hati dan pastikan cleaning descriptor dilakukan sebelum reuse.
  • Integrasikan observabilitas dengan alert yang menandai perubahan drastis pada metrik observabilitas—misal spike latency pada io_uring atau peningkatan error code pada epoll.

Dengan pendekatan ini, tim dapat menjaga agar flaky test tidak jadi kebiasaan, dan transisi antara epoll dan io_uring bisa dilakukan dengan confidence serta data yang jelas.