Apakah Permintaan Lambat di API Gateway Mempengaruhi Permintaan Lain?

Masalah yang sering dibahas dalam ranah API gateway adalah kemampuan untuk menangani sejumlah besar permintaan bersamaan secara efisien. Secara khusus, pertanyaan yang muncul adalah: apakah permintaan yang lambat akan secara signifikan meningkatkan waktu respons permintaan normal lainnya di API gateway?

Jawabannya adalah bahwa APISIX unggul dalam hal ini, menunjukkan bahwa permintaan yang lambat tidak berdampak buruk pada permintaan normal lainnya. Namun, untuk produk API gateway yang berbasis pada bahasa dan arsitektur perangkat lunak yang berbeda, performanya mungkin tidak sebaik itu.

Berbagai bahasa pemrograman menunjukkan tingkat afinitas yang berbeda terhadap arsitektur perangkat lunak bersamaan. Bahasa pemrograman awal seperti C dan Fortran, yang dirancang terutama untuk sistem prosesor tunggal, memiliki dukungan yang terbatas untuk konkurensi. Namun, dengan munculnya lingkungan multiprosesor dan multithreading, bahasa yang lebih baru seperti Java dan Python menggabungkan kemampuan konkurensi dan pemrosesan paralel yang lebih kuat. Bahasa seperti Go bahkan dirancang dengan mempertimbangkan konkurensi, mengintegrasikan model konkurensi mereka dengan fitur bahasa. Dukungan untuk konkurensi dalam bahasa pemrograman tidak hanya mencerminkan lingkungan teknologi pada saat pembuatannya, tetapi juga mengantisipasi skenario aplikasi yang dimaksudkan.

Dengan asumsi ribuan permintaan bersamaan, menggunakan arsitektur multithreading atau multiproses (seperti yang terlihat di Java atau Python) memerlukan alokasi ribuan thread atau proses untuk mengelola konteks permintaan. Mereka yang familiar dengan pemrograman komputer memahami bahwa, bahkan jika sebagian besar thread tetap tidak aktif, sistem operasi mengonsumsi sumber daya perangkat keras dalam mempertahankan ribuan thread atau proses. Namun, menggunakan coroutine (seperti di APISIX dan Golang), thread atau proses tambahan tidak diperlukan meskipun terjadi lonjakan permintaan bersamaan.

Coroutine, thread, dan proses semuanya mewakili pendekatan untuk multitasking tetapi menunjukkan perbedaan utama:

1. Mekanisme Penjadwalan: Penjadwalan thread/proses bersifat preemptive, dan dikelola oleh sistem operasi (OS), yang berarti OS memutuskan kapan harus menginterupsi dan beralih ke thread atau proses lain. Sebaliknya, penjadwalan coroutine bersifat kooperatif, digerakkan secara eksplisit oleh programmer atau pustaka bahasa. Coroutine perlu melepaskan kontrol secara eksplisit untuk memfasilitasi peralihan ke coroutine lain.

2. Overhead: Thread/proses, berada di tingkat sistem operasi, memerlukan sumber daya yang lebih tinggi untuk pembuatan, peralihan, dan penghentian. Sebaliknya, coroutine beroperasi di ruang pengguna, menghasilkan overhead yang relatif lebih rendah untuk pembuatan, peralihan, dan penghentian.

3. Berbagi Data dan Sinkronisasi: Berbagi data antar-thread/proses memerlukan operasi sinkronisasi yang kompleks, seperti kunci mutex, kunci baca-tulis, semafor, dll., untuk mencegah kondisi balapan data. Coroutine, berada dalam thread yang sama, dapat langsung berbagi variabel global tanpa perlu sinkronisasi yang rumit.

Di dunia APISIX, permintaan yang lambat hanya melibatkan menunggu respons upstream, sebuah proses yang terbatas pada mendengarkan peristiwa jaringan tanpa menimbulkan overhead sumber daya sistem tambahan. Kesimpulannya, APISIX tidak mengorbankan waktu respons permintaan normal lainnya karena waktu respons yang diperpanjang dari beberapa permintaan tertentu.