`cgi-bin` ile günde 200 milyon istek sunmak

 (jacob.gold)
7 puan yazan GN⁺ 2025-07-07 | 4 yorum | WhatsApp'ta paylaş
  • İlk web döneminde yaygın olarak kullanılan CGI programlarının, modern donanımda hâlâ yüksek performans verebildiği deneyle doğrulandı
  • CGI, istekleri süreç başına işler; bu da bellek yönetiminin otomatik yapılması ve dağıtımın basit olması gibi avantajlar sağlar
  • Benchmark sonuçları, sıradan bir 16 iş parçacıklı CPU sunucusunda bile saniyede 2400'den fazla, günde 200 milyondan fazla istek işlenebildiğini gösterdi
  • Go dili ve SQLite ile yazılmış guestbook.cgi örnek kodu ile Dockerfile açık kaynak olarak paylaşıldı
  • CGI bugün yaygın kullanılmasa da, hâlâ pratik ve modern bir alternatif olabileceğini gösteriyor

CGI programları ve çalışma mantığı

  • 2000'lerin başında CGI (Common Gateway Interface) programları, dinamik web siteleri kurmanın başlıca yoluydu
  • Çoğu Perl ya da C dili ile yazılıyordu; performansı artırmak için bazen C tercih ediliyordu
  • CGI fikri basit ama güçlüdür
    • Web sunucusu, istek metaverisini (HTTP başlıkları, query vb.) ortam değişkenlerine yerleştirir
    • Ayrı bir süreç oluşturup CGI programını çalıştırır
    • İstek gövdesini stdin üzerinden iletir
    • Programın stdout çıktısını HTTP yanıtı olarak yakalar
    • stderr çıktısını sunucu hata loguna gönderir
    • Program isteği bitirdiğinde süreç sonlanır ve dosya tanımlayıcıları ile bellek otomatik olarak serbest bırakılır
  • Geliştirici açısından yeni sürüm dağıtımı da çok basitti; yalnızca dosyayı cgi-bin/ dizinine kopyalamak yeterliydi

Hug of death (trafik patlaması)

  • 2000'lerin başında çoğu web sunucusunda 1-2 CPU ve 1-4 GB bellek yaygındı
  • Apache web sunucusunun her bağlantı için bir httpd süreci fork etmesi nedeniyle, çok sayıda bağlantıda bellek ihtiyacı artıyordu
  • Eşzamanlı bağlantı sayısı çoğu zaman 100'ü aşmakta zorlanıyordu; ünlü bir siteden yalnızca bağlantı almak bile sunucuyu kolayca aşırı yükleyebiliyordu
    • ( Slashdot Effect : O dönemde popüler olan Slashdot'ta bir bağlantı çıkınca trafik sel gibi akardı. Bugün Hacker News ana sayfasına çıkmaya benzer)

Modern sunucu ortamında CGI

  • Günümüzde 384 CPU iş parçacığına sahip sunucular var; nispeten küçük VM'lerde bile 16 CPU bulunabiliyor
  • CPU ve bellek performansı büyük ölçüde arttı
  • CGI programları ayrı süreç tabanlı olduğu için çok çekirdeği doğal biçimde kullanabiliyor
  • Bu nedenle, modern donanımda CGI programlarının ne kadar hızlı olduğunu görmek için doğrudan benchmark testi yapıldı
  • Deney, AMD 3700X (16 iş parçacığı) sunucusunda gerçekleştirildi

Benchmark'ın başlıca sonuçları

  • Basit bir CGI programı hem Apache hem de Go net/http sunucusu ortamında test edildi

  • guestbook.cgi programının açıklaması

  • HTTP yük üretim aracı plow kullanılarak 16 bağlantı ile 100 bin isteklik testler yapıldı
  • Sıradan donanımda bile saniyede 2.400'den fazla, yani günde 200 milyondan fazla istek işlenebildi
  • CGI bugün ana akım olmasa da, gerçek servis işletiminde hâlâ kullanılabilir

  • Apache ortamında write benchmark'ı

    • Saniyede yaklaşık 2468 istek işlendi, ortalama yanıt gecikmesi 6.47ms oldu
    • 100 bin POST isteği yalnızca 40.5 saniyede işlendi
    • İsteklerin çoğu 7ms içinde yanıtlandı, 100ms'yi aşanlar ise çok azdı
    • Pratikte yüksek yazma performansı gösterildi

  • Apache ortamında read benchmark'ı

    • Saniyede yaklaşık 1959 istek işlendi, ortalama yanıt gecikmesi 8.16ms oldu
    • 100 bin GET isteği 51 saniyede işlendi
    • İsteklerin yarıdan fazlası 8ms içinde tamamlandı, en yüksek gecikme bile 31ms ile sınırlı kaldı
    • Okuma performansı da fazlasıyla yeterliydi

  • Go net/http ortamında write benchmark'ı

    • Saniyede yaklaşık 2742 istek işlendi, ortalama yanıt gecikmesi 5.83ms oldu
    • 100 bin POST isteği 36.4 saniyede işlendi
    • İş hacmi ortalama 2,742 RPS, ortalama gecikme 5.8ms ile Apache'den sayısal olarak daha iyi performans verdi
    • İsteklerin %95'inden fazlası 6ms içinde işlendi
    • Go ortamındaki CGI da pratik kullanım için yeterli performansa sahip

  • Go net/http ortamında read benchmark'ı

    • Saniyede yaklaşık 2469 istek işlendi, ortalama yanıt gecikmesi 6.47ms oldu
    • 100 bin GET isteği 40.4 saniyede işlendi
    • İsteklerin çoğu 7ms içinde sunulabildi
    • Hem okuma iş hacmi hem de yanıt hızı Apache ile benzer ya da daha iyiydi

Sonuç ve bağlantı

  • CGI programları, en yeni donanımda çok yüksek eşzamanlılık, basit dağıtım ve işletim sisteminin otomatik kaynak temizliği gibi avantajlara sahip
  • Modern framework'lere kıyasla son derece basit olsa da, belli ölçekli servislerde bugün de pratik olarak kullanılabilir
  • Ziyaretçi defteri örneği ve benchmark deney verileri aşağıdaki GitHub deposunda paylaşıldı
    https://github.com/Jacob2161/cgi-bin

İlgili okumalar

4 yorum

 
kansm 2025-07-09

Vay be.. yeniden cgi kullanmaya mı başlayacağız?? haha
Vay.. cgi ne zamandan kalma şey..
 
tujuc 2025-07-08

7/7 tarihi itibarıyla güncellenmiş bir içerik varmış.

Serving a half billion requests per day with Rust + CGI

Günde 500 milyon istekmiş...
 
GN⁺ 2025-07-07
Hacker News görüşleri

  • 1990'larda da C ile yazılmış CGI programlarının gerçekten çok hızlı olduğu ortamları hatırlıyorum, ancak çok hata üretmeleri ciddi bir dezavantajdı; yazıda anılan Go programları ya da Nim gibi modern diller ise veritabanı bağlantısı yapmadıkları sürece localhost'ta son derece hızlı ve düşük gecikmeli hissettiriyor, adeta bir CLI yardımcı programında fork & exec kullanıyormuşsunuz gibi; ağ gecikmesiyle kıyaslandığında maliyet neredeyse ihmal edilebilir düzeydeydi

    • Ancak belirli teknolojilere kolayca bağımlı hale gelen bir kültürden de söz ediliyor; örneğin Python interpreter'ı gibi başlangıç maliyeti yüksek dillere alışınca multi-shot ya da kalıcı bir modele ihtiyaç duyuluyor

    • İlk dönem HTTP'nin one-shot modeli, FTP sunucularının yüzlerce boşta oturum açmış oturumu uzun süre bellekte tutacak kadar hafızaya sahip olmaması sorunundan doğmuştu

    • CGI'da pre-forking (gecikmeyi gizleyebilir) ile Rust gibi güvenli bir dili birleştirince mükemmel sistem tasarımları mümkün olabilir; TLS sonlandırmasını çok iş parçacıklı bir web sunucusunda (veya CloudFront benzeri bir katmanda) yapmak da kullanım kolaylığı sağlıyor

      • Durum bırakmayan, core dump almanın ve debug etmenin çok kolay olduğu bir ortam; çoğunlukla doğrusal istek modeliyle ölçeklemek de basit
      • Sadece stdin'den okuyup stdout'a yazma sadeliği övülüyor; Websockets biraz karmaşıklık katıyor ama kaygılanacak düzeyde değil
      • Java'nın yükselişiyle birlikte fork() maliyetinden ve C'nin tehlikelerinden kaçınmak için uygulama sunucularına hızlı bir geçiş yaşandığı hatırlatılıyor; şimdi yeniden sadeliğe dönebiliriz deniyor
      • Rust'ı sevmiyorum ama bu tarz web backend kodlarının kolayca yazılabildiği bir çağ gelirse node/js, php, python geliştiricileri için de çok çekici olabilir

  • CGI döneminden beri geliştirme yaptığım için kısa ömürlü alt süreçler çalıştırmaya karşı güçlü bir önyargım oluştu

    • PHP ve FastCGI'nin, her web isteği için yeni süreç oluşturmanın performans sorunundan kaçmak için ortaya çıktığı açıklanıyor

    • Son donanım gelişmeleri sayesinde süreç başlatma maliyetinin pratikte o kadar da büyük bir sorun olmadığını fark ettim

    • Bu benchmark'ın saniyede 2000 istek işleyebildiği, birkaç yüz istek bile işlese birden fazla instance'a kolayca ölçeklenebildiği gibi modern bir ortamdan söz ediliyor

    • AWS Lambda'nın CGI modelinin yeniden doğuşu olduğu görüşüne katılıyorum, bence oldukça yerinde bir benzetme

    • Eğer CGI script'lerini boyutuna da dikkat edilerek statik linklenmiş C binary'leri olarak dağıtsaydık, hayal kırıklığı daha az olurdu deniyor

      • PHP yorumlayıcısını ya da çeşitli kütüphaneleri yüklemek, dosyaları parse etmek gibi dinamik linkleme kaynaklı süreç başlatma maliyetleri çok daha yüksek
      • Go kullanmanın 25 yıl önce bile gayet rekabetçi olabilecek bir yaklaşım olduğuna inanılıyor
      • SQLite veritabanı açmanın performansı, bir soketi context switch ile devretmeye neredeyse eşdeğer; uzak mysql bağlantısıyla karşılaştırıldığında ise çok daha hızlı olduğu vurgulanıyor
      • FastCGI'nin yeni uygulamalar için hâlâ mükemmel bir seçenek olduğu savunuluyor

    • CGI düşük yük ortamlarında para ve performans açısından çok büyük bir yük değildi

      • Yüksek yük altında FastCGI gibi sürekli çalışan süreçler daha avantajlı
      • CGI de saniyede 2.000 rps'ye kadar çıkabilir, ancak FastCGI çok daha yüksek performans sağlayabilir
      • Ayrı bir sunucu süreci eklemek ve yükseltme sırasında sadece yeniden başlatmak yeterli; performans önemliyse buna değdiği belirtiliyor

    • Go ortaya çıkmadan önce CGI programlarını C/C++ ile yazmak, 2000'lerde hem güvenlik hem de geliştirme zorluğu açısından zordu

      • Perl ve Python'da yorumlayıcı başlangıcı ve derleme maliyeti oldukça yüksekti, Java ise pratikte daha da yavaştı
      • AWS Lambda = CGI modelinin yeniden beden bulmuş hali olduğu görüşüne katılınıyor
      • Şimdi neredeyse yönetilen FastCGI ile aynı modele geri dönmüş gibiyiz
      • Sadece çalıştırılabilir dosyayı yükleyip çalıştırmak yeterli olabilecekken gereksiz yere tonla karmaşıklık ekleyen teknoloji seli üzücü

  • Bugün sunucularda 384 CPU thread var, küçük bir VM bile 16 CPU ile gelebiliyor

    • Böyle bir donanımda Kestrel ile geliştirirseniz günde trilyonlarca isteği rahatlıkla işleyebilirsiniz

    • PHP'ye benzer bir geliştirme deneyimi string interpolation operatörleriyle sağlanabiliyor

    • LINQ ve String.Join() kullanarak HTML tabloları ve iç içe öğeleri kolayca şablonlaştırabilirsiniz

    • Asıl zor olan şey MVC/Blazor/EF gibi ekosistem mayın tarlalarında nasıl yol alınacağını bilmek

    • Tüm programı tek bir üst düzey dosya olarak CLI'dan çalıştırmak da mümkün, ancak "Minimal APIs" anahtar sözcüğünü bilmiyorsanız kendinizi yanlış dokümantasyon labirentinde bulmanız kolay

      • Çekirdek teknolojinin üstüne soyutlama katmanları koyup Director/VP seviyesine terfi eden bu kadar çok insan olmasına şaşırıyorum

  • CGI'nin avantajı, çok kiracılı ortamlarda izolasyon primitive'lerini yeniden inşa etmek gerekmemesi

    • Tek bir istekteki hata, süreç izolasyonu sayesinde diğer istekleri etkilemez
    • Sonsuz döngü bile preemptive scheduling sayesinde hizmet reddine (DoS) dönüşmez
    • rlimit ile uzun süren istekler zorla sonlandırılabilir
    • cgroup kullanılarak kiracı başına bellek, CPU, disk/ağ IO kullanımı adil biçimde paylaştırılabilir
    • Namespace/jail ve yetki ayrımıyla her isteğin erişim hakları sınırlandırılabilir

  • CGI script'leri sayesinde perl hızlı başlangıç süresi için optimize edilmişti

    • time perl -e '' komutunu çalıştırınca perl 5ms, python3 33ms, ruby 77ms sürüyor; bu da perl'in hızlı başlangıcını gösteriyor

      • tcc mob branch'teki #!/bin/tcc -run tarzı script'lerin perl'den 1.3 kat daha hızlı olduğu belirtiliyor
      • Julia, Java VM, thread PHP gibi örneklerde de başlangıç süreleri çok uzayabiliyor
      • İnsanların alışkanlık gereği "büyük ortamlar"a bağımlı hale gelmesi
      • Lisp topluluğunda da image kullanımıyla aynı şeyin tekrarlandığı, "emacs is bloated" memesinin de buradan çıktığı anlatılıyor
      • 90'ların sonlarına doğru Perl'in altın çağının gerçekten CGI sayesinde mümkün olduğu havası vardı
      • O dönemde getline bile standart değildi; bu yüzden üçüncü taraf C kütüphaneleri yüzlerce hatta binlerce satır olabiliyordu
      • Sonuçta teknoloji çoğu zaman "itibar"a göre seçiliyor ve insanlar genelde arkadaşlarının önerisiyle öğreniyor

  • apache tomcat 11 kullanınca .jsp dosyalarını ya da tüm java servlet uygulamasını (.war) ssh ile yüklemek yetiyor ve doğrudan çalışıyor

    • Tek bir paylaşımlı JVM ile en yüksek performans elde ediliyor

    • DB connection pool, cache vb. de uygulamalar arasında paylaşılabiliyor

    • Gerçekten etkileyici bir deneyim

      • Ama bu gerçek kullanım desenine bağlı

      • Büyük ölçekli servisler için harika, fakat her biri günde yalnızca birkaç yüz istek alan 50 küçük uygulamanız varsa Tomcat'in bellek ek yükü, CGI script tabanlı Apache/Nginx'e kıyasla fazla büyük olabilir

      • Dosyaları sadece kopyalayarak deploy ettiğimiz günleri özlüyorum

      • Deploy sürecinin neden bu kadar karmaşık hale geldiğine hayıflanılıyor

      • Hâlâ Jetty ile backend web uygulamalarını keyifle kullandığını paylaşan biri var

      • Tomcat/Jakarta EE/JSP yığınının beklenmedik derecede sağlam olduğu söyleniyor

      • PHP'deki gibi HTML ile kodu iç içe yazmak da mümkün, saf Java route'ları da

      • Websockets desteği var; tek süreçli çok iş parçacıklı model olduğu için gerçek zamanlı iletişimde de güçlü

      • Gerekirse istekler arasında veri paylaşılabiliyor, JSP kodu ise varsayılan olarak request scope ile sınırlı

      • Deploy gerçekten çok kolay; webapps dizinine yeni dosya yüklendiğinde Tomcat yeni uygulamayı otomatik yüklüyor ve eskisini boşaltıyor

      • Dezavantajı ise classloader sızıntıları nedeniyle garbage collection'ın başarısız olabilmesi; bu da tek süreçli modelin kaderi

  • apache istekleri için görselleştirme aracı ibrahimdiallo.com/reqvis yapılmış

    • En iyi deneyim masaüstü tarayıcıda sunuluyor
    • HN trafik verileri üzerinden gerçek çalışma akışı web'de görülebiliyor

  • Son zamanlardaki karmaşık mimari yönelimine şüpheyle bakıyordum; iyi donanımla aslında eski teknolojilerin hâlâ yeterli olabileceği ihtimalinden söz ediliyor

    • Milyonlarca kişiye gerçek zamanlı hisse fiyatı gösterecek bir sistem tasarlama sorusunda önce Kafka, pubsub gibi karmaşık akış yapıları akla gelmiş ama sonunda sunucuya statik dosya koymak gibi basit bir yöntem de düşünülmüş

    • Bunun gerçek işletim maliyetinin ne olacağı merak ediliyor

      • Pratikte neredeyse tüm web API gecikmesi DB sorguları ya da ML model sorguları tarafından belirleniyor
      • Geri kalan süreçler için Python gibi yavaş diller kullanmak bile çok önemli bir fark yaratmıyor
      • Sadece nadiren değişen veri döndürüyorsanız NIC sınırına ulaşmak bile kolay olabilir

  • Serverless mimariye benziyor, ama çok daha basit ve ucuz olduğu vurgulanıyor

    • İş dünyasında bunun gerçekten bu şekilde kullanıldığı örnekler olup olmadığı merak ediliyor

  • Bu geleneksel yapıları yeniden değerlendirmek yerine sadece "serverless functions" diye yeni bir paradigma üretilmiş olmasına üzülenler var

    • Lambda gibi serverless function'larda ayrı koruma mekanizmaları (micro VM vb.) olsa da, aslında sadece CGI ve yetki ayarıyla çok daha az karmaşıklıkla çok daha ileri gidilebileceği düşünülüyor
 
regentag 2025-07-07

cgi neyse de, jsp’ye verilen tepki gerçekten şaşırtıcı haha
jsp gerçekten de artık o kadar eski bir antika mı oldu acaba.