SSE Yanıtları Neden Toplu Geliyor? Proxy Tamponlama

Canlı bildirimleriniz bir süre görünmüyor, ardından aynı anda mı beliriyor? Yapay zekâ yanıtınız parça parça gelmesi gerekirken tek seferde mi görünüyor? SSE, bu güncellemeleri geldikçe göstermeyi sağlar. Ancak uygulamanın veri üretmesi, o verinin hemen ekrana ulaştığı anlamına gelmez; verinin üretilmesini, iletilmesini ve ekranda gösterilmesini ayrı ayrı kontrol etmek gerekir.

Tüm sunucunun ayarlarını değiştirmek yerine, örnek bir Python uygulamasına doğrudan ve Nginx üzerinden bağlanarak ilerleyeceğiz. Böylece gecikmenin hangi yolda başladığını bulabilecek, gerekli ayarı yalnız ilgili yolda değiştirebilecek ve yeni bir bağlantıyla olayların düzenli ulaşıp ulaşmadığını kontrol edebileceksiniz.

SSE akışını anlamak ve örnek ortamı kurmak

SSE (Server-Sent Events), sunucunun açık tuttuğu HTTP yanıtı üzerinden tarayıcıya olay göndermesidir. Böylece siz sayfayı yenilemeden canlı bildirimleri veya yapay zekâ yanıtının parçalarını görebilirsiniz. Ancak verinin uygulamada üretilmesi ile tarayıcıya ulaşması ayrı aşamalardır; gecikmeyi bulmak için bu aşamaları karşılaştırmak gerekir.

Bir SSE olayı data: alanıyla gönderilebilir ve boş satırla tamamlanır. Uygulama çıktıyı kendi belleğinde bekletiyorsa flush, yani yazma tamponunu boşaltma çağrısı gerekir. İsteği uygulamaya ileten ters proxy de yanıt parçalarını biriktirebilir. Bu nedenle uygulamadaki ve aracı sunucudaki beklemeyi ayrı inceleyeceğiz. Tek bir yazma çağrısı, verinin tek ağ paketiyle ulaşacağını veya ekranın hemen güncelleneceğini garanti etmez.

Paketleri kurun ve olay üreten uygulamayı başlatın

Sunucunun terminalinde aşağıdaki komutlarla Python, Nginx ve HTTP yanıtlarını terminalden incelemek için curl paketlerini kurun. Ubuntu 24.04 depolarındaki paketleri kullanacağız. Bu örnek, 9000 ve 8080 portlarının boş olduğunu ve aşağıda oluşturulacak örnek dosyalarının henüz bulunmadığını varsayar; mevcut dosyalarınız varsa üzerlerine yazmadan önce kopyalarını alın.

sudo apt update
sudo apt install -y python3 nginx curl

Aynı terminalde aşağıdaki komutla /tmp/sse-demo.py dosyasını oluşturup uygulamayı başlatın. Python standart kitaplığındaki ThreadingHTTPServer, bağlantıları ayrı iş parçacıklarında ele alır. Her olayın sonundaki çift satır sonu, tarayıcının olayı tamamlanmış saymasını sağlar. wfile.flush() çağrısı da uygulamanın yazma tamponunda bekleyen veri varsa bunu gönderir.

cat > /tmp/sse-demo.py <<'PY'
from datetime import datetime, timezone
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
import time


class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != "/events":
            self.send_error(404)
            return

        self.send_response(200)
        self.send_header("Content-Type", "text/event-stream")
        self.send_header("Cache-Control", "no-cache")
        self.end_headers()

        try:
            for number in range(1, 11):
                stamp = datetime.now(timezone.utc).isoformat()
                event = f"data: {number} {stamp}\n\n"
                self.wfile.write(event.encode("utf-8"))
                self.wfile.flush()
                time.sleep(1)
        except (BrokenPipeError, ConnectionResetError):
            pass


print("SSE uygulaması 127.0.0.1:9000 üzerinde hazır", flush=True)
ThreadingHTTPServer(("127.0.0.1", 9000), Handler).serve_forever()
PY
python3 /tmp/sse-demo.py

Hazır mesajından sonra hata görünmeden terminalin beklemesi normaldir; uygulama ön planda çalışır. Sonraki testlerde istekleri karşılayabilmesi için bu oturumu açık bırakın. Deneme bittiğinde uygulamayı Ctrl+C ile durdurabilirsiniz. Bu geçici servis, üretim ortamında kullanılmak için tasarlanmamıştır.

Nginx üzerinden ikinci erişim yolunu açın

Python’u durdurmadan sunucuya ikinci bir terminal oturumu açın. Nginx, istekleri aynı uygulamaya iletecek; böylece aracı sunucunun akışa etkisini karşılaştırabileceksiniz. Nginx ile ters proxy kurulumu yaklaşımıyla yalnız belirli bir yolu uygulamaya bağlayacağız. Aşağıdaki komutun oluşturduğu dosya, /events isteklerini adres yolunu değiştirmeden Python’a aktarır.

Örnekte Nginx, 127.0.0.1 adresinin 8080 portunu dinler; bu adrese yalnız sunucunun içinden ulaşılır. Bu ayar, paket kurulumu sırasında etkinleşebilen varsayılan siteyi veya başka Nginx dinleme adreslerini kapatmaz.

sudo tee /etc/nginx/conf.d/sse-demo.conf > /dev/null <<'NGINX'
server {
    listen 127.0.0.1:8080;
    server_name localhost;

    location = /events {
        proxy_pass http://127.0.0.1:9000;
        proxy_buffering on;
    }
}
NGINX
sudo nginx -t

Sözdizimi testinde ayarın geçerli olduğunu belirten mesajları görürseniz aşağıdaki komutlarla servisi başlatıp ayarı yükleyin. Test hata verirse yeniden yüklemeye geçmeden bildirilen dosya ve satırı düzeltin, ardından testi tekrar çalıştırın.

sudo systemctl start nginx
sudo systemctl reload nginx

Artık sunucudan 9000 portuna yapılan istek doğrudan Python’a, 8080 portuna yapılan istek ise Nginx üzerinden aynı uygulamaya ulaşır. Başlangıçta proxy_buffering on bıraktık; böylece tamponlamayı kapatmadan önce iki yolu karşılaştırabileceğiz. Bu ayar tek başına olayların mutlaka toplu geleceğini göstermez. Sonraki akış testinde olayların gerçekten hangi aralıklarla ulaştığına bakacağız.

curl ile olayların nerede beklediğini ayırmak

Aynı uygulamaya doğrudan ve Nginx üzerinden bağlanarak gecikmenin hangi yolda ortaya çıktığını ayırabilirsiniz. Python uygulamasının çalıştığı terminali açık tutun; aşağıdaki testleri sunucudaki ikinci terminalde sırayla yapın. Önce mevcut akışı gözleyeceğiz, ardından bulguya göre ilgili ayara geçeceğiz.

Doğrudan uygulama ile Nginx akışını karşılaştırın

İlk komut doğrudan Python uygulamasına bağlanır. -N, curl’ün aldığı veriyi ekrana yazarken kendi tamponunda bekletmesini kapatır; uygulamanın veya Nginx’in tamponlamasını değiştirmez. -i yanıt başlıklarını gösterir, -sS ilerleme göstergesini gizlerken hata mesajlarını görünür bırakır.

curl -sS -N -i http://127.0.0.1:9000/events

Bu örnekte, yaklaşık saniyede bir gelen ve aralarında boş satır bulunan 10 adet data: satırı görmelisiniz. Akış tamamlanınca aynı testi Nginx’in dinlediği 8080 portunda çalıştırın:

curl -sS -N -i http://127.0.0.1:8080/events

Olayların içindeki zaman damgaları üretim zamanını gösterir, curl’e ulaşma zamanını değil. Damgalar birer saniye ilerlediği hâlde satırlar ekranda birlikte beliriyorsa veri, üretim ile ekrana yazılma arasında beklemiştir. İki istek ayrı olay dizileri üretir; bu nedenle damgaların aynı olmasını değil, satırların hangi aralıklarla geldiğini karşılaştırın.

Geliş zamanını ve olay sınırını doğrulayın

Geliş aralıklarını gözle ayırt edemiyorsanız aynı terminalde zaman damgalı curl izini kaydedin. --trace-ascii gönderilen ve alınan veriyi okunabilir biçimde dosyaya yazar; --trace-time her kayda zaman bilgisi ekler.

curl -sS -N --trace-time --trace-ascii /tmp/sse-direct.trace http://127.0.0.1:9000/events
curl -sS -N --trace-time --trace-ascii /tmp/sse-nginx.trace http://127.0.0.1:8080/events

Dosyaları less /tmp/sse-direct.trace ve less /tmp/sse-nginx.trace ile açın. Recv data, curl’ün veri aldığı kayıtları gösterir. Her dosyada bu kayıtlar arasındaki süreye ve içerdikleri olaylara bakın; ardından iki yolun geliş aralıklarını karşılaştırın. Bir kayıt birden fazla olay içerebilir; tek kayıt tek olay demek değildir. Bu örnek hassas veri içermez, ancak gerçek uygulamalarda iz dosyaları kimlik doğrulama bilgilerini ve yanıt içeriğini de saklayabilir.

İlk iki komutun gösterdiği yanıt başlıklarında durumun 200, Content-Type değerinin text/event-stream olduğunu kontrol edin. Farklı bir durum veya içerik türü varsa önce beklediğiniz SSE yanıtına ulaşıp ulaşmadığınızı ayırın. Cache-Control: no-cache önbellek davranışıyla ilgilidir; tamponlamayı kapatmaz. Content-Encoding: gzip görürseniz yanıt sıkıştırılmıştır. Bu tek başına gecikmenin nedenini kanıtlamaz, ancak sıkıştırmayı ayrıca sınamanız gerektiğini gösterir.

• İki yol da gecikiyorsa: Önce uygulamada olayın \n\n ile tamamlandığını ve yazmadan sonra wfile.flush() çağrıldığını kontrol edin. curl tamamlanmamış olayın metnini gösterebilir, fakat tarayıcı boş satır gelmeden olayı uygulamanıza teslim etmez. Eksik olan kısmı düzelttikten sonra doğrudan uygulama testini tekrarlayın.
• Yalnız 8080 gecikiyorsa: Bu yerel örnekte fark Nginx yolundadır. Sonraki adımda yalnız SSE yolunun tamponlama ayarını değiştirip yeni bir bağlantıyla geliş aralıklarını yeniden karşılaştırabilirsiniz.
• İki yol da düzenliyse: Bu testte olayların toplu geldiği gözlenmemiştir. Gecikmenin yaşandığı tarayıcıyı ve gerçek dış erişim yolunu ayrıca inceleyin; yerel test bu katmanları kapsamıyor.

Nginx tamponlamasını yalnız SSE yolunda kapatmak

Doğrudan uygulama akışı düzenliyken yalnız 8080 portundaki akış gecikiyorsa, değişikliği Nginx’in /events yoluyla sınırlayın. Böylece diğer sayfaların ayarlarına dokunmadan SSE yanıtlarının Nginx’te birikmesini önleyebilirsiniz. İki yol da düzenliyse bu değişiklik, tespit edilmiş bir gecikmeyi düzeltmekten çok SSE yolunda tamponlamayı açıkça kapatmaya yarar.

Mevcut ayarı yedekleyip SSE konumunu değiştirin

Python uygulaması çalışmaya devam ederken sunucudaki ikinci terminalde mevcut ayar dosyasının kopyasını alın. Bu kopya, değişiklik öncesindeki ayara dönmenizi sağlar. Komut aynı adlı yedeğin üzerine yazacağı için bu adımı daha önce yaptıysanız ilk yedeğinizi koruyun ve kopyalama komutunu tekrar çalıştırmayın.

sudo cp -p /etc/nginx/conf.d/sse-demo.conf /etc/nginx/conf.d/sse-demo.conf.bak

Yedeği aldıktan sonra aynı terminalde aşağıdaki komutu çalıştırın. Komut, örnek ortam için oluşturduğumuz dosyanın içeriğini aşağıdaki ayarlarla değiştirir. Gerçek sitenizin başka ayarlar da içeren dosyasını bununla değiştirmeyin; burada yalnız deneme dosyası üzerinde ilerliyoruz.

sudo tee /etc/nginx/conf.d/sse-demo.conf > /dev/null <<'NGINX'
server {
    listen 127.0.0.1:8080;
    server_name localhost;

    location = /events {
        proxy_pass http://127.0.0.1:9000;
        proxy_buffering off;
        gzip off;
        proxy_read_timeout 60s;
    }
}
NGINX

location = /events yalnız bu yolla tam eşleşen istekleri kapsar; sonunda eğik çizgi bulunan /events/ farklı bir yoldur. proxy_buffering off, Nginx’in uygulamadan aldığı yanıtı tamponlarda biriktirerek iletmesini kapatır. Bu ayar, her parçanın ayrı bir ağ paketiyle veya sıfır gecikmeyle ulaşacağını garanti etmez.

gzip off, bu konumda Nginx’in yanıtı gzip ile sıkıştırmasını kapatır. Uygulamanın zaten sıkıştırdığı yanıtı açmaz; örnekteki Python uygulaması sıkıştırma yapmıyor.

proxy_read_timeout 60s ise uygulamadan yapılan ardışık okumalar arasındaki bekleme sınırıdır; bağlantının toplam ömrü değildir. Örnekte saniyede bir veri geldiği için normal akışın bu sınıra takılması beklenmez.

Ayarı yükleyin ve yeni bağlantıyla doğrulayın

Dosyayı değiştirmek, çalışan Nginx’in yeni ayarı kullanması için yeterli değildir. Aynı terminalde aşağıdaki komutu çalıştırın. Yeniden yükleme yalnız sözdizimi testi başarılıysa yapılır; reload, Nginx’i durdurmadan yeni ayarı yükler.

sudo nginx -t && sudo systemctl reload nginx

Test hata verirse bildirilen dosya ve satırdaki sorunu düzeltip aynı komutu yeniden çalıştırın. Yeniden yükleme de hatasız tamamlandıktan sonra aşağıdaki komutla yeni bir bağlantı açın. Önceden açılmış bir akış eski ayarla devam edebileceğinden yeni ayarı o bağlantı üzerinden değerlendirmeyin.

curl -sS -N -i -H 'Accept-Encoding: gzip' http://127.0.0.1:8080/events

Beklenen görünüm, yaklaşık saniyede bir ulaşan 10 olaydır. Yanıtın durum kodunun 200, içerik türünün text/event-stream olduğunu kontrol edin. Komut sıkıştırma istediği hâlde yanıt başlıklarında Content-Encoding: gzip bulunmamalıdır. Olaylar hâlâ toplu geliyorsa önceki zaman damgalı curl testini tekrarlayıp geliş aralıklarını karşılaştırın; bu bulgu olmadan başka konumların tampon ayarlarını değiştirmeyin.

Gerekirse önceki ayara dönün

Değişikliği geri almak için sunucudaki ikinci terminalde aşağıdaki komutları çalıştırın. İlk komut yedeği etkin dosyanın yerine koyar; ikinci komut geri yüklenen ayarı test eder ve test başarılıysa Nginx’e yükler.

sudo cp -p /etc/nginx/conf.d/sse-demo.conf.bak /etc/nginx/conf.d/sse-demo.conf
sudo nginx -t && sudo systemctl reload nginx

Ardından aynı curl komutuyla yeni bağlantı açın ve yanıtın hâlâ alınabildiğini kontrol edin. Önceki ayar tamponlamayı açık bıraktığı için olaylar yeniden toplu gelebilir; bu kontrolde amaç, geri dönüşten sonra erişimin çalıştığını görmektir.

Sıkıştırma, ara katmanlar ve tarayıcıdaki gecikmeler

Yerel Nginx yolu olayları düzenli iletiyorsa kalan gecikmenin hangi katmanda başladığını araştırın. Toplu geliş, proxy tamponlamasının yanı sıra sıkıştırmadan veya tarayıcının ekranı güncelleme biçiminden de kaynaklanabilir. Aşağıdaki kontrolleri yalnız ilgili katman varsa uygulayın; Python örneğine yeni bileşen eklemeniz gerekmiyor.

Sıkıştırmayı ve uygulamanın tamponlama başlığını ayırın

Sunucudaki terminalde aynı yolu önce sıkıştırmasız, ardından sıkıştırma isteyerek sınayın. --compressed, curl’ün desteklediği sıkıştırmaları istemesini ve gelen sıkıştırılmış yanıtı açmasını sağlar:

curl -sS -N -i -H 'Accept-Encoding: identity' http://127.0.0.1:8080/events
curl -sS -N -i --compressed http://127.0.0.1:8080/events

Örnekte iki akışın da düzenli, yanıtların sıkıştırmasız olması beklenir. Gerçek uygulamada yalnız sıkıştırılmış yanıt gecikiyorsa Content-Encoding başlığını doğrudan uygulamadan aldığınız yanıttaki değerle karşılaştırın. Bu başlık, yanıta uygulanan sıkıştırmayı gösterir. Uygulama sıkıştırıyorsa mevcut ayarının kopyasını alın ve yalnız SSE yolunu sıkıştırma dışında bırakın; Nginx’teki gzip off uygulamanın sıkıştırmasını kapatmaz. Değişiklikten sonra aynı iki testi tekrarlayın; beklenen etkiyi görmezseniz önceki ayara dönün.

Uygulamanın gönderdiği X-Accel-Buffering: no yanıt başlığı da Nginx’e tamponlamayı kapatmasını söyleyebilir. Ancak ilgili ayarlarda proxy_ignore_headers X-Accel-Buffering; varsa bu başlık dikkate alınmaz. Sunucuda sudo nginx -T çıktısında SSE isteğini karşılayan konumu ve üst düzeyden devraldığı ayarları inceleyin. Nginx bu başlığı normalde istemciye geçirmediğinden tarayıcıda görünmemesi, uygulamanın göndermediğini kanıtlamaz. Mevcut örnekte açıkça yazdığınız proxy_buffering off yeterlidir; ayrıca başlık eklemeniz gerekmez.

CDN gecikmesini boşta bağlantı kopmasından ayırın

CDN, yani içerik dağıtım ağı kullanıyorsanız kendi bilgisayarınızda gerçek HTTPS alan adınızdaki SSE yolunu aynı curl seçenekleriyle sınayın. Yerel yol düzenliyken dış yol toplu geliyorsa CDN’in ilgili yol kuralında önbellek, sıkıştırma ve akış desteğini kontrol edin. Bu fark, dış erişim yolunu incelemeniz gerektiğini gösterir; tek başına CDN’in sorumlu olduğunu kanıtlamaz.

Değişiklik gerekiyorsa mevcut kuralı kaydedip yalnız SSE yolunda ilgili özelliği değiştirin; yeni bağlantıda fark yoksa geri alın. Önbelleği atlamak tek başına tamponlamayı kapatmaz. Sağlayıcının akış desteği ve bağlantı süresi sınırları da değerlendirmeye dahildir.

Olaylar düzenli gelirken yalnız sessiz dönemlerde bağlantı kopuyorsa sorun tamponlama olmayabilir. Uygulama, bağlantıyı canlı tutmak için heartbeat adı verilen periyodik mesajı : ping\n\n biçiminde yazıp tamponunu boşaltabilir. Bu, SSE yorum satırıdır; tarayıcı bunu normal bir olay olarak işleyiciye teslim etmez. Örneğin bilinen en kısa boşta kalma sınırı 60 saniyeyse 15 saniyelik gönderim aralığı bu sınırın altında kalır. Ancak bu mesajlar bağlantının toplam ömrüne konan sınırı ortadan kaldırmaz. Mevcut 10 olaylık örnek uzun sessizliği sınamaz; ayrı bir denemede iş olayı üretilmezken bağlantının açık kaldığını gözleyin.

Tarayıcı çizimini ve PHP yolunu ayrı değerlendirin

Gerçek dış erişim yolunda da curl düzenliyse tarayıcının geliştirici araçlarında Network (ağ) bölümünden akış isteğini açın. Olay geldiğinde çalışan işlevin, yani olay işleyicisinin başında konsola performance.now() değerini yazdırın. Bu değer, çağrının sayfanın zaman başlangıcına göre ne zaman çalıştığını gösterir; ardışık kayıtların farkıyla işleyicinin çalışma aralıklarını karşılaştırabilirsiniz.

İşleyici düzenli çalışırken metin toplu görünüyorsa arayüzün güncellemeleri birleştirmesini veya tarayıcının ana iş parçacığını meşgul eden işleri inceleyin. Deneme ortamında ağır işlemi geçici olarak devre dışı bırakıp aynı akışı yeniden izleyin. Ekran güncellemeleri düzeliyorsa proxy ayarı yerine arayüzdeki işlem yüküne odaklanın.

PHP isteklerini çalıştıran süreç yöneticisi PHP-FPM’e fastcgi_pass ile bağlanan sitelerde farklı bir iletişim yolu vardır: proxy_buffering yerine fastcgi_buffering off; kullanılır. Önce SSE isteğini karşılayan konumun gerçekten bu iletişim yolunu kullandığını kontrol edin. İlgili ayar dosyasını yedekleyip değişikliği yalnız SSE konumuna ekleyin; sözdizimi testi başarılıysa Nginx ayarını yeniden yükleyin. Yeni bağlantıda akışı karşılaştırın; geri dönmeniz gerekirse yedeği yerine koyup yine testten sonra yükleyin.

PHP tarafında üretilen çıktı daha Nginx’e ulaşmadan bekliyorsa PHP çıktı tamponlarını ve sıkıştırmasını inceleyin. Yalnız flush() çağrısı bütün katmanları boşaltmaz; uygulamanın kendi çıktı tamponunda tuttuğu veriyi de göndermesi gerekir.

Sık Sorulan Sorular

Bağlantı kopunca olaylar kaybolur mu?

Bağlantının yeniden kurulması, arada kaçırılan olayların geri geleceği anlamına gelmez. Tarayıcının yerleşik SSE istemcisi EventSource, bağlantı kesildiğinde normalde yeniden bağlanmayı dener. Sunucu olaylara id: alanı eklerse istemci yeniden bağlantıda son olay kimliğini Last-Event-ID başlığıyla iletebilir.

Kayıpsız devam için uygulamanızın bu kimliği okuyup ardından gelen, saklanmış olayları yeniden göndermesi gerekir. Aynı olayın iki kez işlenmesini önlemek için tekrar gelen olayları kimliklerine göre ayıklayın. Örnekteki Python uç noktası olay geçmişi tutmadığından kayıpsız devam sağlamaz.

EventSource ile kimlik doğrulaması nasıl yapılır?

Yerleşik EventSource arayüzü özel Authorization başlığı eklemenize izin vermez. Aynı kaynakta, yani aynı protokol, alan adı ve portta, oturum çerezi kullanabilirsiniz. Başka bir kaynağa çerezle bağlanmak için withCredentials: true ve sunucuda uygun CORS, yani kaynaklar arası erişim izinleri gerekir. Bu izinler verilse bile tarayıcının çerez kısıtlamaları geçerliliğini korur.

Erişim belirtecini başlıkla göndermeniz gerekiyorsa fetch üzerinden akışı okuyabilirsiniz. Bu durumda gelen veriyi SSE olaylarına ayırmayı ve yeniden bağlanma mantığını da sizin yönetmeniz gerekir. Uzun ömürlü belirteçleri URL’ye koymayın; erişim günlüklerine kaydedilebilirler.

SSE için HTTP/2 zorunlu mu?

Hayır, SSE HTTP/1.1 üzerinde de çalışır. HTTP/2, tek bağlantıda birden fazla akış taşıyarak çok sekmeli kullanımda tarayıcının bağlantı sınırlarının etkisini azaltabilir. Yine de eşzamanlı akış sayısı sınırsız değildir. HTTP/2’ye geçmeniz, uygulamanın veya ters proxy’nin veriyi bekletmesini önlemez; protokol değişikliği tamponlama düzeltmesinin yerine geçmez.

Bir sunucu kaç SSE bağlantısı taşıyabilir?

Her sunucu için geçerli tek bir sayı yoktur. Kapasite; açık bağlantı sınırlarına, belleğe, uygulamanın eşzamanlı çalışma modeline, olay sıklığına ve yavaş istemciler için biriken veriye bağlıdır. Hesabınıza yalnız tarayıcı bağlantılarını değil, Nginx’in uygulamaya açtığı bağlantıları da katın.

Örnekteki ThreadingHTTPServer her bağlantı için ayrı iş parçacığı kullanır; üretimdeki uygulamanızın kapasitesini temsil etmez. Kendi sınırınızı görmek için üretimden ayrı bir yük testinde eşzamanlı bağlantı sayısını beklediğiniz kullanıcı sayısına doğru kademeli artırın. Bellek kullanımını, açık bağlantı sayısını, olayların ulaşma gecikmesini ve bağlantı kopmalarını birlikte izleyin.

Yayına geçmeden önce akış kontrol listesi

Nginx ayarının yüklenmiş olması tek başına yeterli değildir; olayların kullanıcıya beklediğiniz aralıklarla ulaşması gerekir. Aşağıdaki kontrollerle hem yerel akışı hem de gerçek uygulamanın dışarıdan erişildiğinde nasıl davrandığını sınayabilirsiniz.

• Doğrudan ve proxy akışı: Sunucuda curl -N ile önce 127.0.0.1:9000/events, ardından 127.0.0.1:8080/events yolunu sınayın. Örnek uygulamada her iki yolda da 10 olayın yaklaşık birer saniye arayla görünmesi beklenir. Yalnız olayların içindeki zaman damgalarının farklı olması yeterli değildir; satırların ekrana geliş aralıklarını karşılaştırın.
• Tarayıcı görünümü: Gerçek uygulamada olay işleyicisinin çağrıldığı anlarla ekran güncellemelerini karşılaştırın. Olaylar düzenli alındığı hâlde metin toplu görünüyorsa proxy yerine arayüzün güncellemeleri birleştirip birleştirmediğini veya ağır işlemler nedeniyle bekletip bekletmediğini inceleyin.
• Boşta bağlantı: On olaylık örnekten ayrı olarak, uygulamanın yeni bildirim üretmediği uzun bir aralığı sınayın. Bağlantıyı canlı tutan heartbeat mesajlarının ulaştığını ve bağlantının beklediğiniz sessiz dönem boyunca açık kaldığını kontrol edin.
• Geri dönüş: /etc/nginx/conf.d/sse-demo.conf.bak yedeğini koruyun. Değişikliği geri almanız gerekirse yedeği etkin dosyaya kopyalayın; sudo nginx -t başarılı olduktan sonra sudo systemctl reload nginx çalıştırın. Ardından yeni bir bağlantı açıp akışın hâlâ alınabildiğini kontrol edin.
• Üretim yolu: Deneme amaçlı Python sunucusunu üretim servisi olarak kullanmayın. Gerçek uygulamada yetkisiz erişimin engellendiğini ve bağlantı koptuğunda yeniden bağlanmanın beklendiği gibi çalıştığını kontrol edin. Beklenen eşzamanlı bağlantı yükünü üretimden ayrı bir yük testinde sınayın.

Bir sonraki adım, kendi bilgisayarınızdan gerçek HTTPS alan adındaki SSE yolunu curl -N ve tarayıcıyla sınamak olsun. Böylece yerel testte bulunmayan CDN ve yük dengeleyici gibi ara katmanları da denemeye katarsınız. Yerel akış düzenli, dış akış topluysa çalışan uygulama ayarlarını değiştirmek yerine bu ek katmanların SSE yoluna uyguladığı kuralları inceleyin.