Windows Sunucu ve IIS ile Yüksek Trafikli Site Rehberi

Windows sunucu ile yoğun trafik altında istikrarlı yayın

Gerçek hayatta yüksek trafikli site yöneten herkes bilir; sorun çoğu zaman koddan değil altyapıdan patlar. Özellikle bir windows sunucu üzerinde IIS ile yayın yapıyorsanız, birkaç yanlış varsayımla dakikalar içinde CPU tavan, bellek sızıntısı, kuyruk dolması ve zaman aşımı hatalarıyla uğraşabilirsiniz. Doğru planlanmış bir IIS yapılandırma ise aynı donanımda çok daha fazla isteği stabil şekilde karşılayabilir.

Bu rehberde odak noktası, üretim ortamında çalışan yüksek trafikli site senaryoları olacak. Tek bir blog değil; kampanya döneminde saniyede yüzlerce isteğe çıkan e-ticaret, yoğun API çağrıları veya yüksek sayıda eşzamanlı oturuma sahip kurumsal uygulamalar gibi baskı altında kalan sistemlerden bahsediyoruz. Tüm örnekler windows hosting altyapısında, Windows Server + IIS kombinasyonu üzerinden ilerleyecek.

Buradaki adımların her biri, günün birinde “neden yavaşladık?” sorusunu daha az sormanızı sağlamak için tasarlandı. Yapılandırmayı adım adım ele alalım.

Mimariyi tasarlamak: Tek sunucudan dağıtık yapıya

Performans ayarlarına girmeden önce, mimariyi netleştirmek gerekiyor. Yüksek trafikli site kavramı, tek bir windows sunucu ile çözülemeyecek kadar yoğun olabilir. Bu yüzden öncelikle dikey ve yatay ölçekleme seçeneklerini masaya koymalısınız.

Donanım ve kapasite planlama

İlk soru genelde şu olur: “Kaç CPU, ne kadar RAM yeter?” Cevap, uygulamanın doğasına bağlı, ama bazı pratik sınırlar var. IIS tarafında CPU çekirdek sayısı, eşzamanlı istekleri karşılama kapasitesini doğrudan etkiler. Hafıza ise hem .NET runtime hem de cache kullanımı için kritik. Başlangıç için kabaca şu yaklaşım mantıklıdır:

• Orta trafik (aynı anda 200-500 kullanıcı): 4 vCPU, 8-16 GB RAM
• Yüksek trafik (aynı anda 500-2000 kullanıcı): 8 vCPU, 16-32 GB RAM
• Çok yüksek trafik (API veya dev kampanya dönemleri): 16+ vCPU, 32+ GB RAM, tercihen çoklu sunucu

Depolama tarafında IOPS değeri ihmal edilmemeli. Log dosyaları, temp dosyalar, cache ve statik içerikler aynı disk üzerinde yarışıyorsa, en güçlü CPU bile sizi kurtarmaz. Mümkünse loglar ve içerik dosyaları için ayrı diskler planlayın.

Ağ topolojisi ve güvenlik katmanları

Yüksek trafikli site mimarisinde, IIS genellikle doğrudan internete açılmaz. Tipik olarak öne bir ters vekil (reverse proxy) veya donanımsal load balancer gelir, arka tarafta ise bir veya birden fazla windows sunucu üzerinde IIS worker süreçleri çalışır. Uygulama sunucusunun doğrudan dış dünyaya açık olmaması, hem güvenlik hem de performans açısından büyük avantaj sağlar.

Eğer modern bir bulut veya sanal sunucu altyapısı kullanıyorsanız, örneğin VPS.TC üzerindeki VPS ya da bulut sunucu servisleriyle, aynı datacenter içinde yük dengeleyici ve web sunucularını ayrı makinelerde konumlandırmak oldukça pratik hale geliyor. Böylece trafik dalgalandığında ek IIS düğümleri ekleyip yatayda ölçekleyebilirsiniz.

Yüksek trafikli senaryolar için temel IIS yapılandırma adımları

Şimdi windows sunucu tarafında kritik IIS yapılandırma başlıklarına geçelim. Burada her ayar, doğrudan üretim ortamında hissettiğiniz metrikleri etkiler: cevap süresi, hata oranı, CPU kullanımı, bellek tüketimi ve kuyruk dolma olayları gibi.

Application Pool mimarisini doğru kurgulamak

Her yüksek trafikli site için ilk durak, Application Pool ayarlarıdır. Varsayılan ayarlarla gelen birçok pool, geliştirme ortamında idare eder ama üretim için agresif sayılabilecek geri dönüşüm (recycle) davranışlarına sahiptir. Aşağıdaki ilkeleri uygulamak, istikrarı ciddi biçimde iyileştirir:

• Uygulamaları mantıklı şekilde ayrı App Pool altında çalıştırın. Ağır iş yapan API ile statik içerik sunan siteyi aynı pool altında toplamayın.
• “Start Automatically” özelliğini açık tutun; sunucu restart sonrası pool otomatik ayağa kalksın.
• “Idle Time-out” süresini yüksek trafikli site için genellikle 0 (devre dışı) yapmak mantıklıdır; aksi halde düşük trafikli anlarda pool durur, sonra gelen ilk istekte soğuk başlama yaşanır.
• “Regular Time Interval” ile saatlik recycle ayarını körü körüne kullanmayın. Kritik uygulamalarda belirli zaman aralıkları yerine, mümkünse manuel veya gece düşük trafik saatlerinde zamanlanmış recycle tercih edin.
• “Private Memory Limit” ve “Virtual Memory Limit” ayarlarında gerçekçi eşikler belirleyin; bellek sızıntısı şüphesi yoksa, bu limitleri gereksiz yere kısıtlamayın.

Birçok ekipte yapılan hata, memory leak korkusuyla çok agresif recycle ayarları yapmak. Bunun sonucu, kullanıcıların ortasında session kaybı, uzun yanıt süreleri ve 503 hataları olur. Sorunu saklamış olursunuz ama çözmemiş.

Worker process ve queue length ayarları

App Pool altında çalışan w3wp süreçlerinin sayısı (“Maximum Worker Processes” veya web garden) ve HTTP.SYS kuyruğu (queue length) yüksek trafikte belirleyicidir. Çoğu senaryoda tek worker process idealdir; state managment, cache ve connection pool paylaşımı açısından daha öngörülebilir davranır.

Queue Length varsayılanı genellikle 1000 civarındadır. Çok yüksek trafikli bir windows hosting ortamında bu kuyruk dolarsa, 503 hataları almaya başlarsınız. Kuyruk kapasitesini artırmak için Application Pool gelişmiş ayarlarından “Queue Length” değerini, test sonuçlarınıza göre 5000 veya 10000 seviyelerine çekebilirsiniz. Ancak bu ayarı artırmak, sorunu çözmez; sadece semptomu geciktirir. Kuyruk neden doluyor, onu da izlemek gerekir.

HTTP sıkıştırma ve statik içerik optimizasyonu

Basit görünen ama en yüksek kazanım sağlayan ayarlardan biri, HTTP sıkıştırma ve statik dosya optimizasyonudur. Yüksek trafikli site çoğunlukla aynı JS, CSS, görsel ve font dosyalarını tekrar tekrar servis eder. IIS üzerinde aşağıdakileri etkinleştirmek iyi bir başlangıçtır:

• Statik sıkıştırma (static compression) etkin ve önbelleğe alınmış şekilde yapılandırılmalı.
• Dinamik içerik sıkıştırması (dynamic compression) için CPU kullanımını gözlemleyerek kademeli açın; yoğun CPU tüketen sayfalarda dikkatli olun.
• “StaticContent” modülünde uygun cache-control ve Expires üstbilgilerini (header) ayarlayın; CDN veya tarayıcı cache verimliliği artar.

Bu ayarlar, doğrudan bant genişliği ve cevap süresi üzerinde etkilidir. Basitçe söylemek gerekirse; aynı donanımla daha fazla kullanıcıya hizmet vermiş olursunuz.

web.config ve makine düzeyi ayarlarda dikkat edilmesi gerekenler

Çoğu proje, web.config içine rastgele eklenen ayarlarla yıllarca yaşar. Yüksek trafik söz konusu olduğunda, bu dosya artık performans aracı haline gelir. Özellikle ASP.NET uygulamaları için aşağıdaki başlıklara bakmak şart.

CustomErrors, tracing ve logging davranışları

Geliştirme sürecinde açık duran ayrıntılı hata sayfaları, tracing mekanizmaları ve verbose log ayarları, üretimde ciddi yük oluşturur. Yüksek trafikli site için aşağıdaki pratikleri uygulayın:

• “customErrors” modunu üretimde her zaman “On” veya en azından “RemoteOnly” yapın.
• Detaylı tracing sadece spesifik endpoint veya kısa süreli hata analizi için açılmalı; kalıcı açık bırakmayın.
• Uygulama loglamasını dosya bazlı yapıyorsanız, log boyutunu ve rotasyon politikasını mutlaka belirleyin; tek dosya içinde gigabaytlarca log tutmayın.

Logları merkezi sisteme göndermek (ELK, Splunk, Azure Application Insights vb.) genellikle daha ölçeklenebilir bir yaklaşım. Ama hangi çözümü seçerseniz seçin, synchronous dosya yazımından kaçının.

Connection limitleri ve timeout değerleri

Yüksek trafikli bir API veya web uygulamasında, upstream sistemlere (veritabanı, cache, üçüncü parti servisler) açılan bağlantı sayısı, bütün sistemi kilitleyebilir. web.config içinde connection string ayarlarını, connection pool parametrelerini ve HTTP timeout değerlerini gözden geçirmek gerekir.

Örneğin SQL Server için connection pool ayarlarını optimize etmek, IIS tarafında thread starvation sorunlarını azaltır. Her isteğin uzun süren bir veritabanı çağrısında beklediği bir senaryoda, IIS tarafındaki her optimizasyon sınırlı kalır.

Windows hosting ortamında ölçeklenebilirlik ve yük dengeleme stratejileri

Tek bir windows sunucu, bir noktaya kadar işi taşır. Özellikle CPU kullanımınız sürekli %70-80 seviyesinde geziyorsa ve dikeyde (daha güçlü makine) büyümek maliyetli hale geldiyse, yatay ölçeklemeye geçme zamanı gelir. IIS bu noktada iki farklı yaklaşımla öne çıkar.

Uygulama sunucularını çoğaltmak

En klasik yöntem, aynı uygulamayı birden fazla windows sunucu üzerine kurup, önlerine bir yük dengeleyici (load balancer) koymaktır. Bu, ister donanımsal load balancer isterse yazılımsal bir reverse proxy olsun, mantık aynıdır: gelen istekler farklı IIS düğümlerine dağıtılır.

Burada kritik soru şudur: Oturum (session) yönetimi nasıl? Eğer session bilgisi bellekte tutuluyorsa ve sticky session (client aynı node a yönlendirilir) kullanmıyorsanız, kullanıcı deneyimi bozulur. Daha sağlıklı yaklaşım, session bilgisini dışarı almaktır: Redis, SQL Server veya state server gibi. Böylece herhangi bir windows sunucu isteği cevaplayabilir.

Uygulama durumunu dış sistemlere taşımak

Cache, session, kullanıcı durumu gibi veriler uygulama sunucusunun belleğinde tutuldukça, yatayda genişlemek zorlaşır. Yüksek trafikli site mimarisinde sıkça yapılan iyileştirmeler şunlardır:

• Session state in process yerine out-of-process veya SQL/Redis üzerinde tutulması
• Uygulama cache inin dağıtık cache sistemlerine taşınması
• Upload edilen dosyaların yerel disk yerine paylaşımlı dosya sistemi veya nesne depolama servislerinde saklanması

Böylece yeni bir windows sunucu eklemek, sadece IIS kurup aynı uygulamayı deploy etmek kadar basit hale gelir. Altyapıyı örneğin VPS.TC Sanal Veri Merkezi gibi esnek bir katmanda kurduğunuzda, ölçekleme operasyonu dakikalar içinde tamamlanabilir.

Kaynak kullanımı izleme ve performans testleri

IIS yapılandırma işinin en çok ihmal edilen bölümü, izleme ve testtir. Birçok ekip, yalnızca gerçek kullanıcı trafiğiyle sınanmış sistemlere sahiptir. Bu da en kötü senaryonun, en beklenmedik anda karşınıza çıkması anlamına gelir.

Windows sunucu üzerinde temel izleme pratikleri

Öncelikle, canlı bir sistemde ne olup bittiğini anlık görmek için birkaç temel araçtan vazgeçmeyin. Örneğin SSH benzeri şekilde PowerShell ile bağlandığınızda aşağıdaki komut, çalışan IIS süreçlerini hızlıca görmenizi sağlar:

Get-Process w3wp

Bu komutla hangi uygulama havuzunun ne kadar CPU ve bellek kullandığını anında görebilirsiniz. Daha derin analizler için Performance Monitor (perfmon) üzerinde aşağıdaki sayaçlara özellikle bakın:

• Processor(_Total) – % Processor Time
• Memory – Available MBytes
• ASP.NET veya .NET CLR Exceptions sayaçları
• Web Service veya HTTP Service sayaçları (Current Connections, Queue Length)

Bunları grafikli olarak izlemek, hangi saatlerde trafik pik yaptığını, hangi kaynakların sınırda gezdiğini net biçimde ortaya koyar.

Yapay yük testleri ve dar boğaz tespiti

Gerçek kullanıcı trafiği oluşmadan önce, yapay yük testi yapmak zor ama gereklidir. Apache JMeter, k6 gibi araçlarla saniyede kaç istek geldiğinde sistemin bozulmaya başladığını tespit edebilirsiniz. Bu testleri yaparken sadece ortalama cevap süresine değil, hata oranına ve CPU/IO kullanımına da bakmak önemli.

İyi bir pratik de, web.config veya IIS ayarlarını değiştirdikten sonra kısa süreli stress testleri yapmaktır. Ayarın net etkisini, yalnızca grafiklere bakarak görebilirsiniz. Örneğin dinamik sıkıştırmayı açtığınızda CPU artar ama yanıt süreleri düşer; sizin için optimum dengeyi test ederek bulmanız gerekir.

Güvenlik, patch yönetimi ve felaket senaryoları

Performans konuşurken güvenliği atlamak, üretim ortamında yapılabilecek en riskli hareketlerden biridir. Yüksek trafikli site aynı zamanda saldırganlar için de cazip bir hedeftir. windows sunucu tarafında aşağıdaki başlıklar mutlaka günlük işlerin parçası olmalı:

• Düzenli Windows Update ve IIS ile ilgili güvenlik yamalarının uygulanması
• Uygulama veya sistem konfigürasyonu değişmeden önce ve sonra snapshot veya yedek alınması
• Web.config, sertifikalar ve hassas kimlik bilgilerinin şifrelenmiş şekilde tutulması
• RDP, WinRM gibi yönetim portlarının doğrudan internete açık olmaması

Felaket senaryosu için en azından şu soruların cevabı hazır olmalı: Sunucu tamamen kaybolursa uygulamayı kaç dakikada başka bir windows sunucu üzerine ayağa kaldırabiliyorum? Veritabanı yedeği hangi aralıklarla alınıyor ve geri dönüş test ediliyor mu? Bu sorulara net cevap veremiyorsanız, konfigürasyon ne kadar iyi olursa olsun risk altındasınız.

IIS üzerinde tipik sorunlar ve pratik çözüm yolları

Gerçek üretim ortamında, belli şikayetler tekrar tekrar karşınıza çıkar. Bunların bir kısmı yanlış yorumlanır ve yanlış yere odaklanılır. Örnek birkaç durum üzerinden gidelim.

CPU sürekli yüksek: Kod mu, konfigürasyon mu?

CPU sürekli %80 üzerinde geziyorsa, ilk refleks genelde “sunucu yetersiz” olur. Oysa çoğu durumda, verimsiz sorgular veya sonsuz döngüye yakın algoritmalar asıl suçludur. Yine de IIS tarafında yapabileceğiniz birkaç şey var:

• Failed Request Tracing ile uzun süren istekleri yakalayın.
• Uygulama logları üzerinden en çok çalışan endpointleri analiz edin.
• Gerekirse .NET profilleyici ile sıcak pathleri ortaya çıkarın.

Eğer analiz sonunda gerçekten CPU sınırına dayanmışsanız, o zaman ya daha güçlü bir windows sunucuya geçmek ya da ek IIS düğümleriyle yatayda ölçeklemek gerekir.

503 Service Unavailable ve kuyruk dolması

Yüksek trafikli site ortamında en sinir bozucu hata 503 tür. Genellikle Application Pool durması, kuyruk dolması veya worker crash i ile ilgilidir. Olası adımlar:

• Event Viewer altında System ve Application loglarını kontrol edin.
• App Pool un gerçekten çalışıp çalışmadığını doğrulayın.
• Queue Length ve CPU limit ayarlarını gözden geçirin.

Bu tip sorunlar, çoğu zaman test ortamında fark edilmez; çünkü gerçek dünyadaki trafik modeli laboratuvarda birebir üretmek zordur. Bu yüzden canlı sistemde güçlü izleme şarttır.

Örnek konfigürasyon profilleri

Teoriyi biraz daha somutlaştırmak için, farklı trafik seviyeleri için kabaca düşünülebilecek konfigürasyon profillerini bir tabloda toplayalım. Bunlar elbette genel hatlar; her proje için test ve ölçüm yapmadan birebir uygulanmamalı.

Bu tip bir profile göre başlangıç kurulumu yaptıktan sonra, gerçek trafik altında ölçüm alıp ayarları rafine etmek en sağlıklı yol olur.

Yüksek trafikli IIS altyapısını uzun vadede sağlıklı tutmak

Son noktaya gelirken, şunu net söylemekte fayda var: Yüksek trafikli site yönetmek, bir kere konfigürasyon yapıp bırakacağınız bir iş değil. windows sunucu ve IIS birleşimi doğru kurgulandığında son derece sağlam çalışır; ama işin sırrı sürekli gözlem, küçük ayarlarla optimizasyon ve doğru zamanda ölçekleme hamlesi yapmaktır.

Pratik bir yaklaşım izlemek isterseniz şu sırayı takip edebilirsiniz: Önce uygulamayı güvenilir bir windows hosting altyapısına (örneğin VPS.TC üzerindeki VDS veya VPS çözümlerine) taşıyın, ardından temel IIS yapılandırma adımlarını uygulayın, sonra da stres testleriyle dar boğazları bulun. Gerektiğinde yeni IIS düğümleri ekleyerek veya mevcut sunucuyu güçlendirerek ölçekleyin.

İlk adım olarak mevcut sunucunuzda App Pool ayarlarınızı, queue length değerlerinizi ve sıkıştırma seçeneklerinizi kontrol edin. Küçük dokunuşlarla bile ciddi kazanımlar elde edildiğini göreceksiniz. Sonrasında, otomatik izleme ve merkezi loglama kurarak sistemin nabzını sürekli tutmanız, uzun vadede hem uykunuzu hem de uptime oranlarınızı koruyacaktır. Kısacası, windows sunucu üzerinde doğru IIS yapılandırma ile yüksek trafikli siteyi sadece ayakta tutmakla kalmaz, aynı donanımda daha çok kullanıcıya sorunsuz hizmet verirsiniz.