Hangi WSGI sunucusunu seçmelisiniz?

Giriş

Python web uygulamaları üretim ortamında doğrudan çalıştırılmaz; HTTP isteklerini Python callable'larına çevirmek için bir WSGI sunucusuna ihtiyaç duyar. WSGI (Web Server Gateway Interface), PEP 3333 ile tanımlanan bu arayüzün standardıdır ve Flask, Django gibi framework'lerin sunucudan bağımsız çalışmasını sağlar.

Piyasada en çok karşılaşılan iki üretim sunucusu uWSGI ve Gunicorn'dur. uWSGI C ile yazılmış, çok özellikli ve nginx entegrasyonu güçlü bir uygulama sunucusudur. Gunicorn ise pre-fork modeliyle basit, Python odaklı ve genellikle daha az konfigürasyon gerektiren bir alternatiftir.

Bu rehberde her iki sunucunun mimarisini, işçi modelini, bellek kullanımını, ölçeklendirme stratejilerini ve operasyonel karmaşıklığı karşılaştıracağız.

WSGI Standardı Nasıl Çalışır?

WSGI uygulaması tek bir callable'dır: application(environ, start_response). environ sözlüğü CGI ortam değişkenlerini içerir; start_response durum kodu ve header'ları ayarlamak için çağrılır.

Bu soyutlama sayesinde Django uygulamanızı Gunicorn, uWSGI veya mod_wsgi ile aynı kod tabanından çalıştırabilirsiniz. Sunucu seçimi performans, process yönetimi ve reverse proxy entegrasyonu üzerinde doğrudan etkilidir.

def simple_app(environ, start_response):
    status = '200 OK'
    headers = [('Content-Type', 'text/plain')]
    start_response(status, headers)
    return [b'Hello WSGI']

Gunicorn Mimarisi

Gunicorn master process + worker process modeli kullanır. Master sinyalleri dinler, worker'ları spawn eder ve ölüleri yeniden başlatır. Varsayılan sync worker her isteği tek thread'de işler.

Konfigürasyon genelde komut satırı veya gunicorn.conf.py ile yapılır. Basitlik Gunicorn'un en büyük avantajıdır: birkaç satırla Django veya Flask uygulaması ayağa kalkar.

• Pre-fork worker modeli
• Graceful reload: kill -HUP master PID
• sync, gevent, eventlet worker sınıfları
• systemd ile doğrudan entegrasyon

# gunicorn.conf.py
bind = '127.0.0.1:8000'
workers = 4
worker_class = 'sync'
timeout = 30
max_requests = 1000

uWSGI Mimarisi

uWSGI yalnızca WSGI sunucusu değil; tam bir uygulama konteyneridir. HTTP, FastCGI, SCGI ve uwsgi protokolünü destekler. Emperor/spawn modeli ile tek makinede yüzlerce site yönetilebilir.

C tabanlı olması ve zengin eklenti ekosistemi uWSGI'yi büyük ölçekli deployment'larda tercih edilir. Öğrenme eğrisi daha diktir; ini dosyası yüzlerce parametre içerir.

[uwsgi]
module = myproject.wsgi:application
master = true
processes = 4
threads = 2
socket = /run/uwsgi/myapp.sock
chmod-socket = 660
vacuum = true

Performans ve Kaynak Kullanımı

Mikro benchmark'larda uWSGI ve Gunicorn benzer throughput verebilir; asıl fark iş yükü profiline bağlıdır. CPU-bound Django view'larında process sayısı = (2 x CPU) + 1 kuralı her iki sunucuda da geçerlidir.

uWSGI'nin dahili cache ve routing özellikleri ek process gerektirmez. Gunicorn tarafında Redis veya Memcached ayrı katman olarak kurulur.

1. CPU-bound: sync worker
2. I/O-bound: gevent veya ASGI
3. Bellek sızıntısı: max-requests
4. Yüksek trafik: nginx + unix socket

Operasyonel Karşılaştırma

Gunicorn logları stdout'a akar; systemd journal ile kolay toplanır. uWSGI logrouter ve multiple logger desteği sunar ancak konfigürasyon daha karmaşıktır.

Docker ortamında Gunicorn genelde daha az sürpriz çıkar. uWSGI imajları ini dosyası volume mount ve socket izinleri dikkat gerektirir.

Basit bir API için Gunicorn yeterli; çok siteli shared hosting veya gelişmiş process kontrolü için uWSGI daha güçlü bir seçimdir.

Hangi Senaryoda Hangisi?

Tek Django projesi, orta trafik, systemd ile yönetim: Gunicorn ideal başlangıç noktasıdır. Aynı sunucuda 10+ farklı Python uygulaması: uWSGI Emperor modu tercih edin.

Geleneksel VPS'lerde nginx + uWSGI socket hala yaygın ve performanslıdır. Ekip deneyimi de belirleyicidir.

ExecStart=/venv/bin/gunicorn --bind unix:/run/gunicorn.sock --workers 4 myproject.wsgi:application

Sonuç

WSGI sunucu seçimi dini bir tartışma değil, gereksinim analizidir. Gunicorn sadelik ve hızlı devreye alma sunar; uWSGI derin kontrol ve ölçek sunar.

Performans farkı çoğu projede darboğaz olmaz; veritabanı sorguları ve cache stratejisi genelde daha kritiktir.