Melayani 200 Juta Request per Hari dengan `cgi-bin`

 (jacob.gold)
7 poin oleh GN⁺ 2025-07-07 | 4 komentar | Bagikan ke WhatsApp
  • Program CGI yang banyak digunakan pada era awal web terbukti lewat eksperimen masih dapat memberikan performa tinggi di hardware modern
  • CGI memproses request per proses, sehingga pengelolaan memori berlangsung otomatis dan deployment menjadi sederhana
  • Hasil benchmark membuktikan bahwa bahkan pada server biasa dengan CPU 16 thread, sistem ini mampu menangani lebih dari 2.400 request per detik, atau lebih dari 200 juta request per hari
  • Contoh kode guestbook.cgi yang ditulis dengan Go dan SQLite beserta Dockerfile dirilis sebagai open source
  • Meski CGI kini tidak lagi umum dipakai, hasil ini menunjukkan bahwa CGI masih bisa menjadi alternatif yang praktis dan modern

Program CGI dan Cara Kerjanya

  • Pada awal 2000-an, program CGI (Common Gateway Interface) merupakan cara utama untuk membangun situs web dinamis
  • Sebagian besar ditulis dengan Perl atau bahasa C, dan C kadang dipilih untuk meningkatkan performa
  • Konsep CGI sederhana, tetapi kuat
    • Web server menetapkan metadata request (header HTTP, query, dan sebagainya) dalam environment variable
    • Membuat proses terpisah untuk menjalankan program CGI
    • Mengirim body request melalui stdin
    • Menangkap stdout program sebagai respons HTTP
    • Meneruskan output stderr ke server error log
    • Setelah program selesai menangani request, proses berakhir sehingga file descriptor dan memori dibebaskan secara otomatis
  • Dari sudut pandang developer, deployment versi baru juga sangat mudah karena cukup menyalin file ke direktori cgi-bin/

Hug of death (lonjakan trafik besar)

  • Pada awal 2000-an, sebagian besar web server umumnya berjalan dengan 1–2 CPU dan memori 1–4GB
  • Karena Apache web server menggunakan struktur yang melakukan fork proses httpd untuk tiap koneksi, kebutuhan memori meningkat saat koneksi bertambah banyak
  • Sulit menangani lebih dari 100 koneksi simultan, dan server sering mudah kewalahan hanya karena mendapat tautan dari situs terkenal
    • ( Slashdot Effect : ketika tautan muncul di Slashdot yang saat itu sangat populer, trafik langsung membludak. Mirip seperti masuk ke puncak Hacker News sekarang)

CGI di Lingkungan Server Modern

  • Kini sudah ada server dengan 384 thread CPU, dan bahkan VM yang relatif kecil pun bisa menyediakan 16 CPU
  • Performa CPU dan memori meningkat sangat besar
  • Karena program CGI berbasis proses terpisah, multicore dapat dimanfaatkan secara alami
  • Karena itu dilakukan benchmark langsung untuk mengukur seberapa cepat program CGI di hardware modern
  • Eksperimen dijalankan pada server AMD 3700X (16 thread)

Hasil Utama Benchmark

  • Program CGI sederhana diuji baik di lingkungan Apache maupun server Go net/http

  • Penjelasan program guestbook.cgi

    • Diimplementasikan sebagai program buku tamu sederhana yang memungkinkan pengunjung meninggalkan komentar di bagian bawah situs web
    • Menggunakan Go dan SQLite, dirancang sesederhana mungkin tetapi tetap realistis
    • Source code dan Dockerfile dibuka di GitHub
  • Menggunakan alat pembangkit beban HTTP plow untuk menjalankan 100 ribu request dengan 16 koneksi
  • Bahkan pada hardware biasa, sistem ini dapat menangani lebih dari 2.400 request per detik, yaitu lebih dari 200 juta request per hari
  • Walau CGI bukan lagi arus utama saat ini, CGI tetap bisa dipakai untuk operasi layanan nyata

  • Benchmark write di lingkungan Apache

    • Menangani sekitar 2468 request per detik, dengan latensi respons rata-rata 6.47ms
    • Menyelesaikan 100 ribu request POST hanya dalam 40,5 detik
    • Sebagian besar request direspons dalam 7ms, hanya sangat sedikit yang melampaui 100ms
    • Membuktikan performa pemrosesan write yang tinggi secara praktis

  • Benchmark read di lingkungan Apache

    • Menangani sekitar 1959 request per detik, dengan latensi respons rata-rata 8.16ms
    • Menyelesaikan 100 ribu request GET dalam 51 detik
    • Lebih dari separuh request selesai dalam 8ms, dan latensi maksimum hanya 31ms
    • Performa baca juga sangat baik

  • Benchmark write di lingkungan Go net/http

    • Menangani sekitar 2742 request per detik, dengan latensi respons rata-rata 5.83ms
    • Menyelesaikan 100 ribu request POST dalam 36,4 detik
    • Throughput rata-rata mencapai 2.742 RPS, dengan latensi rata-rata 5,8ms, secara angka lebih baik daripada Apache
    • Lebih dari 95% request diproses dalam 6ms
    • CGI di lingkungan Go juga memiliki performa yang cukup untuk penggunaan nyata

  • Benchmark read di lingkungan Go net/http

    • Menangani sekitar 2469 request per detik, dengan latensi respons rata-rata 6.47ms
    • Menyelesaikan 100 ribu request GET dalam 40,4 detik
    • Sebagian besar request dapat dilayani dalam 7ms
    • Baik throughput baca maupun kecepatan respons setara atau lebih baik dibanding Apache

Kesimpulan dan Tautan

  • Program CGI memiliki kelebihan seperti konkurensi sangat tinggi di hardware terbaru, deployment sederhana, dan sistem operasi membebaskan resource secara otomatis
  • Meski sangat sederhana dibanding framework modern, CGI masih bisa dipakai secara nyata untuk layanan dengan skala tertentu
  • Contoh buku tamu dan data eksperimen benchmark dipublikasikan di GitHub berikut
    https://github.com/Jacob2161/cgi-bin

Bacaan terkait

4 komentar

 
kansm 2025-07-09

Wah.. apakah kita jadi memakai CGI lagi?? haha
Wow.. sudah sejak kapan CGI itu..
 
tujuc 2025-07-08

Sepertinya ada pembaruan per tanggal 7/7.

Serving a half billion requests per day with Rust + CGI

Sampai 500 juta request...
 
GN⁺ 2025-07-07
Komentar Hacker News

  • Mengingat lingkungan pada tahun 1990-an ketika program CGI yang ditulis dalam C benar-benar menunjukkan kecepatan tinggi, tetapi diakui kelemahannya adalah sering terjadi error; program Go yang disebut di artikel atau bahasa modern seperti Nim, selama tidak melakukan koneksi database, terasa sangat cepat dan latensinya sangat rendah di localhost, seperti menggunakan fork & exec pada utilitas CLI; dibandingkan latensi jaringan, biayanya nyaris bisa diabaikan

    • Namun juga disebut adanya budaya yang mudah kecanduan pada teknologi tertentu; misalnya, setelah terbiasa dengan bahasa yang biaya start-up-nya besar seperti interpreter Python, orang jadi merasa perlu model multishot atau persisten

    • Model one-shot pada HTTP awal bermula dari masalah kurangnya memori sehingga server FTP tidak mampu mempertahankan ratusan sesi login idle dalam waktu lama

    • Disebut bahwa menggabungkan pre-forking pada CGI (yang bisa menyembunyikan latensi) dengan bahasa aman seperti Rust membuka kemungkinan desain sistem yang sangat baik; terminasi TLS bisa ditangani oleh web server multithreaded (atau lapisan seperti CloudFront), sehingga terasa praktis

      • Lingkungan tanpa state sisa, core dump dan debug yang sangat mudah, serta skalabilitas yang sederhana terutama dengan model request linear
      • Memuji kesederhanaan karena cukup membaca dari stdin dan menulis ke stdout; Websockets memang sedikit menambah kompleksitas, tetapi tidak sampai mengkhawatirkan
      • Mengingat kembali arus perpindahan cepat ke application server yang dipicu kebangkitan Java, demi menghindari biaya fork() dan bahaya C; sekarang dianggap sudah bisa kembali ke kesederhanaan
      • Walau tidak menyukai Rust, ada harapan bahwa jika era ketika kode backend web dengan cara seperti ini mudah ditulis benar-benar datang, pendekatan ini juga akan terasa menarik bagi developer node/js, php, dan python

  • Memulai pengembangan sejak era CGI membuat ada pengalaman memiliki penolakan yang kuat terhadap menjalankan subproses berumur pendek

    • Dijelaskan bahwa PHP dan FastCGI lahir untuk keluar dari masalah performa akibat membuat proses baru pada tiap request web

    • Berkat perkembangan hardware terbaru, kini disadari bahwa biaya memulai proses sebenarnya bukan masalah besar

    • Disebut bahwa benchmark ini dapat menangani 2000 request per detik, dan bahkan jika hanya perlu menangani beberapa ratus, lingkungan modern memudahkan scaling ke banyak instance

    • Setuju dengan pendapat yang menggambarkan AWS Lambda sebagai kelahiran kembali model CGI; dianggap analogi yang cukup tepat

    • Disebut bahwa jika skrip CGI didistribusikan sebagai binary C static-linked sambil memperhatikan ukurannya, kekecewaannya mungkin akan lebih kecil

      • Biaya start-up proses dari dynamic linking seperti memuat interpreter PHP, berbagai library, dan parsing file jauh lebih besar
      • Yakin bahwa memakai Go adalah pendekatan yang bahkan 25 tahun lalu pun sudah cukup kompetitif
      • Ditekankan bahwa membuka database SQLite performanya hampir setara dengan meneruskan socket lewat context switch, dan jauh lebih cepat dibanding koneksi mysql jarak jauh
      • Menegaskan bahwa FastCGI masih merupakan pilihan yang sangat baik untuk aplikasi baru

    • CGI tidak terlalu membebani dari sisi biaya maupun performa di lingkungan beban rendah

      • Dalam situasi beban tinggi, proses yang berjalan terus-menerus seperti FastCGI lebih menguntungkan
      • CGI juga bisa menangani hingga 2.000 rps, tetapi FastCGI mampu mencapai performa yang jauh lebih tinggi
      • Cukup menambahkan proses server terpisah dan hanya perlu restart saat upgrade; disebut bernilai saat performa menjadi penting

    • Sebelum Go muncul, membuat program CGI dengan C/C++ pada era 2000-an memiliki tantangan besar baik dari sisi keamanan maupun tingkat kesulitan pengembangan

      • Perl dan Python memiliki biaya start interpreter dan kompilasi yang cukup besar, sedangkan Java pada praktiknya bahkan lebih lambat
      • Setuju bahwa AWS Lambda = reinkarnasi model CGI
      • Sekarang rasanya kita kembali ke model yang hampir sama dengan FastCGI terkelola
      • Ada penyesalan terhadap banjir teknologi yang menambahkan begitu banyak kompleksitas padahal seharusnya cukup dengan mengunggah executable lalu menjalankannya

  • Kini kita hidup di zaman server dengan 384 thread CPU, dan bahkan VM kecil pun bisa punya 16 CPU

    • Dengan hardware seperti ini, jika dikembangkan dengan Kestrel, menangani triliunan request per hari pun terasa mudah

    • Pengalaman pengembangan yang mirip PHP bisa diberikan melalui operator string interpolation

    • Dengan LINQ dan String.Join(), tabel HTML dan elemen bertingkat bisa dengan mudah dibuat sebagai template

    • Hal yang benar-benar sulit adalah mengetahui cara menghindari ladang ranjau ekosistem seperti MVC/Blazor/EF

    • Bahkan seluruh program bisa dijalankan dari CLI sebagai satu file tingkat atas, tetapi jika tidak tahu kata kunci "Minimal APIs", mudah sekali tersesat ke labirin dokumentasi yang keliru

      • Terasa mengejutkan bahwa sangat banyak kasus orang menumpuk layer abstraksi di atas teknologi inti lalu dipromosikan ke posisi Director/VP

  • Kelebihan CGI adalah di lingkungan multitenant tidak perlu membangun ulang primitive isolasi

    • Meski ada bug pada satu request, request lain tidak terpengaruh berkat isolasi proses
    • Infinite loop juga tidak langsung berujung pada denial of service (DoS) karena adanya preemptive scheduling
    • Dengan rlimit, request yang memakan waktu terlalu lama bisa dihentikan paksa
    • Dengan cgroup, penggunaan memori, CPU, dan disk/network IO per tenant bisa dialokasikan secara adil
    • Namespace/jail dan pemisahan hak akses memungkinkan pembatasan izin akses untuk tiap request

  • Berkat skrip CGI, perl dioptimalkan untuk waktu start yang cepat

    • Saat menjalankan perintah time perl -e '', terlihat perl memerlukan 5ms, python3 33ms, dan ruby 77ms, yang menunjukkan cepatnya waktu start perl

      • Disebut bahwa skrip gaya #!/bin/tcc -run dari branch tcc mob 1,3 kali lebih cepat daripada perl
      • Julia, Java VM, thread PHP, dan lainnya juga menjadi contoh waktu start yang sangat panjang
      • Fenomena orang yang secara kebiasaan bergantung pada "lingkungan besar"
      • Di komunitas Lisp pun hal ini terulang dengan penggunaan image, dan meme "emacs is bloated" lahir dari sini
      • Masa kejayaan Perl pada pertengahan hingga akhir 1990-an benar-benar dimungkinkan oleh CGI
      • Mengenang masa ketika bahkan getline belum menjadi standar, sehingga library C pihak ketiga dibuat sepanjang ratusan hingga ribuan baris
      • Pada akhirnya teknologi dipilih berdasarkan "reputasi", dan kebanyakan pembelajaran terjadi lewat rekomendasi teman

  • Jika mencoba apache tomcat 11, cukup unggah file .jsp atau seluruh aplikasi java servlet (.war) lewat ssh dan semuanya langsung berjalan

    • Satu JVM bersama memberikan performa maksimum

    • Connection pool DB, cache, dan sebagainya juga bisa dibagi antar aplikasi

    • Pengalaman yang benar-benar mengesankan

      • Ini bergantung pada pola penggunaan nyata

      • Sangat bagus untuk layanan berskala besar, tetapi jika ada 50 aplikasi kecil yang masing-masing hanya menangani beberapa ratus request per hari, overhead memori Tomcat dianggap terlalu besar dibanding Apache/Nginx berbasis skrip CGI

      • Ada kesan rindu pada masa ketika deployment cukup dengan menyalin file

      • Keluhan tentang mengapa proses deployment menjadi serumit ini

      • Berbagi pengalaman bahwa sampai sekarang masih senang memakai Jetty untuk backend webapp

      • Kesan bahwa stack Tomcat/Jakarta EE/JSP ternyata cukup kokoh

      • Seperti PHP, HTML dan kode bisa dicampur, dan route Java murni juga dimungkinkan

      • Mendukung Websockets, dan karena modelnya single-process multithread, ada kelebihan untuk komunikasi real-time

      • Jika perlu, data bisa dibagi per request; kode JSP pada dasarnya dibatasi pada request scope

      • Deployment benar-benar mudah; cukup unggah file baru ke direktori webapps, lalu Tomcat otomatis memuat aplikasi baru dan membongkar aplikasi lama

      • Kekurangannya adalah kebocoran classloader dapat menyebabkan garbage collection gagal, takdir khas model single-process

  • Membuat alat visualisasi untuk request apache: ibrahimdiallo.com/reqvis

    • Pengalaman terbaik tersedia di browser desktop
    • Alur kerja nyata dapat dilihat di web berdasarkan data trafik HN

  • Ada kecurigaan terhadap situasi sekarang yang terus bergerak ke arsitektur rumit; disebut kemungkinan bahwa sebenarnya teknologi lama pun masih bisa dipakai dengan hardware yang bagus

    • Saat pertama kali memikirkan desain sistem untuk memberi informasi harga saham real-time kepada jutaan orang, yang terbayang adalah struktur stream kompleks seperti Kafka, pubsub, dan sebagainya; tetapi kemudian juga terpikir pendekatan sederhana dengan menaruh file statis di server

    • Penasaran dengan biaya operasional nyata dari pendekatan seperti ini

      • Secara praktis, latensi hampir semua web API ditentukan oleh query DB atau query model ML
      • Proses sisanya, meski memakai bahasa lambat seperti Python, tetap tidak seberapa
      • Jika hanya mengembalikan data yang jarang berubah, sangat mudah mencapai batas NIC

  • Ditekankan bahwa ini mirip arsitektur serverless, tetapi jauh lebih sederhana dan murah

    • Penasaran apakah benar ada kasus penggunaan seperti ini di lapangan bisnis nyata

  • Ada penyesalan bahwa tanpa benar-benar meninjau ulang struktur tradisional seperti ini, yang muncul malah sekadar paradigma baru bernama "serverless functions"

    • Walaupun serverless function seperti Lambda memiliki mekanisme perlindungan terpisah seperti microVM, pada dasarnya dirasa bahwa hanya dengan CGI dan pengaturan izin saja kita sebenarnya bisa melangkah jauh dengan kompleksitas yang jauh lebih rendah
 
regentag 2025-07-07

Kalau soal cgi sih masih bisa dimaklumi, tapi reaksi terhadap jsp cukup mengejutkan ya wkwk.
Apakah jsp memang sudah jadi peninggalan kuno sampai sejauh itu.