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 Windows Server 2022 veya Windows Server 2025 üzerinde IIS 10 ile yayın yapıyorsanız, birkaç yanlış varsayımla dakikalar içinde CPU tavanı, bellek baskısı, kuyruk dolması ve zaman aşımı hatalarıyla uğraşabilirsiniz. Doğru planlanmış bir IIS yapılandırması ise aynı donanımda daha fazla isteği daha öngörülebilir biçimde karşılayabilir.

Ben bunu bir kampanya gecesinde yaşayarak öğrendim. Trafik artınca ilk baktığımız gösterge CPU oldu; asıl sorun ise uygulamanın veritabanı bağlantıları serbest bırakılmadığı için IIS worker process’lerinin beklemesiydi. CPU’yu artırmak yerine bağlantı havuzunu, istek sürelerini ve uygulama loglarını birlikte inceledik. O günden beri tek bir grafiğe bakarak kapasite kararı vermiyorum.

Burada 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 10 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ı. Ayarları körlemesine uygulamak yerine ölçerek ilerleyin.

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 sunucuyla çö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, isteklerin ne kadarının dinamik olduğuna ve veritabanının nerede çalıştığına bağlıdır. IIS tarafında CPU çekirdek sayısı eşzamanlı iş kapasitesini etkiler; RAM ise .NET runtime, dosya önbelleği ve uygulama cache’i için kritiktir. Başlangıç için kabaca şu yaklaşım kullanılabilir:

• Orta trafik, ağırlıklı olarak kurumsal site: 4 vCPU, 8-16 GB RAM
• Yoğun e-ticaret veya API: 8 vCPU, 16-32 GB RAM
• Dalgalı kampanya trafiği veya yüksek eşzamanlı API kullanımı: 16 veya daha fazla vCPU, 32 GB ve üzeri RAM, tercihen birden fazla düğüm

Bunlar kapasite garantisi değil, yük testi için başlangıç noktalarıdır. Aynı sayıda kullanıcı, cache kullanan statik ağırlıklı bir sitede başka; her istekte veritabanına giden bir API’de bambaşka kaynak tüketir.

Depolama tarafında IOPS değeri ihmal edilmemeli. Log dosyaları, geçici dosyalar, cache ve statik içerikler aynı disk üzerinde yarışıyorsa en güçlü CPU bile sizi kurtarmaz. Mümkünse uygulama verileri, IIS logları ve yedekleme iş yükü için ayrı disk veya en azından ayrı depolama politikaları 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), CDN veya yük dengeleyici gelir; arka tarafta ise bir veya birden fazla Windows sunucu üzerinde IIS worker process’leri çalışır. Uygulama sunucusunun yönetim portlarının doğrudan dış dünyaya açık olmaması, güvenlik açısından özellikle önemlidir.

Modern bir bulut veya sanal sunucu altyapısı kullanıyorsanız, örneğin VPS.TC üzerindeki VPS ya da bulut sunucu servisleriyle aynı veri merkezinde yük dengeleyici ve web sunucularını ayrı makinelerde konumlandırmak pratik hale geliyor. Trafik dalgalandığında ek IIS düğümleri ekleyebilir, sağlık kontrolleriyle sorunlu düğümü havuzdan çıkarabilirsiniz.

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

Şimdi Windows Server tarafında kritik IIS yapılandırma başlıklarına geçelim. Her ayar; cevap süresi, hata oranı, CPU kullanımı, bellek tüketimi ve kuyruk davranışı gibi üretim metriklerini etkileyebilir. Değişiklikleri önce staging ortamında deneyin ve mümkünse her değişiklik için geri dönüş planı hazırlayın.

Application Pool mimarisini doğru kurgulamak

Her yüksek trafikli site için ilk durak Application Pool ayarlarıdır. Varsayılan değerler küçük uygulamalarda idare edebilir; ancak üretimde uygulamanın açılış süresi, bellek davranışı ve oturum modeli birlikte değerlendirilmelidir. Şu ilkeler iyi bir başlangıç sağlar:

• 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 yeniden başladıktan sonra pool otomatik olarak ayağa kalksın.
• “Idle Time-out” varsayılan olarak 20 dakikadır. Sürekli trafik alan uygulamalarda 0 ile devre dışı bırakmak soğuk başlangıcı azaltabilir; ancak düşük trafikli sitelerde bunun RAM maliyetini ve uygulamanın kendi yaşam döngüsünü hesaba katın.
• “Regular Time Interval” varsayılanı olan 29 saatlik recycle davranışını körlemesine değiştirmeyin. Kritik uygulamalarda planlı recycle gerekiyorsa düşük trafik saatlerini seçin ve worker process’in yeniden başlama süresini ölçün.
• “Private Memory Limit” ve “Virtual Memory Limit” varsayılan olarak 0, yani sınırsız olabilir. Bellek sızıntısı kanıtı yoksa gereksiz düşük eşikler belirlemeyin; limit kullanıyorsanız recycle olaylarını ayrıca izleyin.
• Üretimde uygulama durumunun process belleğine bağlı olup olmadığını kontrol edin. In-process session veya cache kullanılıyorsa recycle sırasında veri kaybı ve soğuk cache oluşabilir.

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

Worker process ve queue length ayarları

App Pool altında çalışan w3wp.exe süreçlerinin sayısı (“Maximum Worker Processes” veya web garden) ve HTTP.sys kuyruğu yüksek trafikte belirleyicidir. Çoğu uygulamada tek worker process daha öngörülebilirdir; session, uygulama cache’i ve bağlantı havuzları process’ler arasında paylaşılmaz. Web garden ancak uygulamanızın çoklu process davranışını test ettiyseniz düşünülmeli.

Application Pool için Queue Length varsayılanı çoğu IIS kurulumunda 1000’dir. Bu kuyruk dolduğunda 503 hataları görebilirsiniz. Değeri 5000 veya 10000’e yükseltmek bazı ani trafik darbelerinde tampon sağlayabilir; fakat işleme kapasitesi artmaz. Kuyruk neden doluyor, worker process neden bekliyor ve upstream sistem ne kadar sürede yanıt veriyor, bunları birlikte izlemek gerekir.

Queue Length değerini PowerShell ile değiştirmek yerine önce ilgili pool’un adını doğrulayın. Örneğin:

Import-Module WebAdministration
Set-ItemProperty "IIS:AppPoolsUygulamaPoolu" -Name queueLength -Value 5000

Bu satırdaki pool adı örnektir; üretimde kopyala-yapıştır yapmadan önce Get-ChildItem IIS:AppPools ile adı kontrol edin. Kuyruğu büyütmeden önce 503.2 ve ilgili WAS olaylarını da inceleyin.

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

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

• Static Content ve Static Compression rollerinin kurulu olduğundan emin olun. Statik sıkıştırma IIS tarafından önbelleğe alınabildiği için CPU maliyeti dinamik sıkıştırmaya göre daha öngörülebilirdir.
• Dynamic Compression’ı CPU ve yanıt süresi birlikte izlenerek açın. Zaten sıkıştırılmış JPEG, WebP, AVIF veya ZIP dosyalarını tekrar sıkıştırmaya çalışmayın.
• Değişmez dosyalara uzun süreli Cache-Control ve uygun Expires başlıkları verin. Dosya adlarına içerik hash’i eklemek, güvenli uzun süreli cache kullanımını kolaylaştırır.
• HTTP/2’yi TLS ile birlikte test edin. HTTP/3 ise IIS sürümünden bağımsız olarak işletim sistemi, TLS, reverse proxy ve ağ katmanlarının birlikte desteklemesini gerektirir; destekleniyor varsayımıyla üretimde açmayın.

Bu ayarlar bant genişliği tüketimini azaltabilir ve istemcinin dosyaları yeniden istemesini önleyebilir. TTFB’yi milisaniye milisaniye tartışmadan önce cache başlıklarının gerçekten çalışıp çalışmadığına bakmak çoğu zaman daha kazançlıdır.

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 performans ve davranış kontrolünün bir parçası haline gelir. Her değişiklikten önce dosyanın yedeğini alın ve mümkünse sürüm kontrolünde tutun.

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 gereksiz yük oluşturabilir. ASP.NET Framework uygulamalarında şu pratiklere bakın:

• customErrors modunu üretimde genellikle On, kontrollü bir iç ağ senaryosunda ise RemoteOnly yapın.
• ASP.NET Core uygulamalarında customErrors ayarı yerine ortam değişkenini Production olarak belirleyin ve geliştirici hata sayfasını etkinleştirmeyin.
• Failed Request Tracing ve ayrıntılı tracing’i yalnızca belirli bir hata analizi için, kısa süreli açın. Kalıcı olarak açık bırakılan trace logları hem diski hem de uygulamayı gereksiz yere meşgul eder.
• Dosya tabanlı log kullanıyorsanız boyut, rotasyon, saklama süresi ve disk kotasını belirleyin. Tek bir dosyanın gigabaytlarca büyümesini beklemeyin.

Bir gece logların ayrılan diski doldurduğu bir sistemde uygulama hatası sandığımız şey aslında yazma işlemlerinin başarısız olmasıydı. O olaydan sonra log rotasyonunu kurulumun son işi değil, ilk kontrollerinden biri olarak görüyorum.

Logları merkezi sisteme göndermek (ELK, Splunk, Azure Application Insights veya benzeri) çok düğümlü yapılarda aramayı kolaylaştırır. Hangi ürünü seçerseniz seçin, her istekte senkron ve pahalı bir dosya yazma işlemi yapmayın; log seviyesini ve kişisel veri politikasını da baştan belirleyin.

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çindeki uygulama ayarlarını, connection pool parametrelerini ve HTTP timeout değerlerini körlemesine yükseltmek yerine isteklerin nerede beklediğini ölçün.

Örneğin SQL Server connection pool ayarlarını optimize etmek IIS tarafındaki thread starvation sorunlarını azaltabilir. Fakat her isteğin uzun süren bir veritabanı çağrısında beklediği senaryoda IIS ayarlarının etkisi sınırlı kalır. Dış servislere kısa ve anlamlı timeout’lar, iptal edilebilir istekler ve kontrollü retry politikaları ekleyin; başarısız bir upstream’i sınırsız tekrarlarla daha da boğmayın.

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

Tek bir Windows sunucu bir noktaya kadar işi taşır. CPU kullanımı sürekli yüzde 70-80 seviyesinde geziyorsa, bellek baskısı veya disk kuyruğu oluşuyorsa ve dikey büyümek maliyetli hale geldiyse yatay ölçeklemeyi değerlendirme 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 koymaktır. Donanımsal load balancer, bulut yük dengeleyicisi veya yazılımsal reverse proxy kullanılabilir. Mantık aynıdır: gelen istekler sağlık kontrolünden geçen IIS düğümlerine dağıtılır.

Burada kritik soru şudur: Oturum yönetimi nasıl? Session bilgisi bellekte tutuluyorsa ve sticky session kullanılmıyorsa kullanıcı aynı akış içinde farklı düğümlere gittiğinde sorun yaşayabilir. Sticky session geçici bir çözüm olabilir; daha sağlıklı yaklaşım session bilgisini Redis, SQL Server veya uygun bir state server gibi dış bir sisteme taşımaktır.

Uygulama durumunu dış sistemlere taşımak

Cache, session ve kullanıcı durumu 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:

• In-process session yerine out-of-process, SQL Server veya Redis tabanlı session kullanılması
• 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ı
• Uygulama dağıtımının tekrarlanabilir hale getirilmesi; düğümlerin elle farklılaştırılmaması

Böylece yeni bir Windows sunucu eklemek yalnızca IIS kurup uygulamayı kopyalamaktan ibaret kalmaz; konfigürasyon, sertifika, bağlantı bilgileri ve sağlık kontrolü de aynı prosedürle uygulanır. Altyapıyı örneğin VPS.TC Sanal Veri Merkezi gibi esnek bir katmanda kurduğunuzda ölçekleme operasyonu daha yönetilebilir hale gelir.

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

Canlı bir sistemde ne olduğunu anlık görmek için birkaç temel araçtan vazgeçmeyin. PowerShell üzerinden çalışan IIS süreçlerini hızlıca görmek için şu komut kullanılabilir:

Get-Process w3wp | Select-Object Id, CPU, WorkingSet64, StartTime

Bu çıktı process başına CPU süresi ve çalışma kümesini gösterir; tek başına hangi App Pool’a ait olduğunu kesin biçimde söylemez. PID ile eşleştirmek için aşağıdaki komut daha açıklayıcıdır:

Get-CimInstance Win32_Process -Filter "Name = 'w3wp.exe'" | Select-Object ProcessId, CommandLine

Komut satırındaki uygulama havuzu adını gördüğünüzde doğru süreci inceleyebilirsiniz. Daha derin analizler için Performance Monitor üzerinde şu sayaçlara bakın:

• Processor(_Total) – % Processor Time
• Memory – Available MBytes
• Process(w3wp) – Private Bytes ve % Processor Time
• ASP.NET veya .NET CLR sayaçları; uygulamanın kullandığı .NET sürümüne göre uygun sayaç seti
• Web Service ve HTTP Service sayaçları; Current Connections ve Queue Length

ASP.NET Core uygulamalarında yalnızca eski ASP.NET sayaçlarına güvenmeyin. Uygulama metrikleri, Windows olay günlükleri, IIS logları ve reverse proxy metrikleri birlikte değerlendirilmelidir.

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 veya benzeri araçlarla saniyede kaç istek geldiğinde sistemin bozulmaya başladığını tespit edebilirsiniz. Testleri üretim kullanıcılarına ve gerçek veritabanına zarar vermeyecek izole bir ortamda gerçekleştirin.

Sadece ortalama cevap süresine değil, p95 ve p99 gecikmeye, hata oranına, CPU ve disk kullanımına, veritabanı bağlantı sayısına da bakın. Bir ayarı değiştirdikten sonra kısa bir stress testi yapmak faydalıdır; dinamik sıkıştırma örneğinde CPU artarken ağ üzerinden taşınan veri azalabilir. Sizin için doğru dengeyi grafikler gösterir.

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 Server ve IIS tarafında şu başlıklar günlük işlerin parçası olmalı:

• Windows Update, IIS bileşenleri, .NET runtime ve kullanılan üçüncü taraf kütüphanelerin güvenlik güncellemelerinin kontrollü uygulanması
• Uygulama veya sistem konfigürasyonu değişmeden önce ve sonra snapshot ya da yedek alınması
• Web.config, sertifikalar ve hassas kimlik bilgilerinin şifrelenmiş veya güvenli bir secret store içinde tutulması
• RDP ve WinRM gibi yönetim portlarının doğrudan internete açık olmaması; mümkünse VPN, bastion veya kısıtlı kaynak IP’leri kullanılması
• İnternete açık IIS bileşenlerinin ve yönetim yüzeylerinin envanterinin tutulması

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? Sertifika ve DNS değişiklikleri nasıl geri alınacak? Bu sorulara net cevap veremiyorsanız yapılandırma 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 yüzde 80 üzerinde geziyorsa ilk refleks genelde “sunucu yetersiz” olur. Oysa verimsiz sorgular, yoğun serileştirme veya sonsuz döngüye yaklaşan algoritmalar asıl suçlu olabilir. IIS tarafında şu adımlarla başlayın:

• Failed Request Tracing ile belirli URL’lerde uzun süren istekleri yakalayın.
• IIS ve uygulama logları üzerinden en çok çalışan endpoint’leri analiz edin.
• CPU örneklemesi ve .NET profilleyicisiyle sıcak path’leri ortaya çıkarın.
• İş yükünün web process’inde mi, veritabanında mı, yoksa dış serviste mi beklediğini ayırın.

Analiz sonunda gerçekten CPU sınırına dayanmışsanız daha güçlü bir Windows sunucuya geçmek veya ek IIS düğümleriyle yatay ölçeklemek gerekir. Sadece App Pool queue değerini artırmak CPU’yu düşürmez.

503 Service Unavailable ve kuyruk dolması

Yüksek trafikli site ortamında en sinir bozucu hatalardan biri 503’tür. Application Pool’un durması, rapid-fail protection, kuyruk dolması, worker process çökmesi veya upstream beklemeleri farklı 503 alt durumları üretebilir. Olası adımlar:

• Event Viewer altında Application, System ve WAS olay günlüklerini kontrol edin.
• App Pool’un çalışıp çalışmadığını ve w3wp.exe sürecinin yeniden başlayıp başlamadığını doğrulayın.
• IIS loglarında sc-status ve sc-substatus alanlarını inceleyin.
• Queue Length, CPU limitleri, rapid-fail protection ve uygulamanın bağımlı olduğu veritabanı veya API’lerin gecikmesini birlikte gözden geçirin.

Bu tip sorunlar test ortamında fark edilmeyebilir; çünkü gerçek dünyadaki trafik modeli laboratuvarda birebir üretmek zordur. Bu yüzden canlı sistemde güçlü izleme ve değişiklik kaydı şarttır.

Örnek konfigürasyon profilleri

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

Bu 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ı yoldur. Özellikle “agresif connection pooling” gibi ifadeler tek başına hedef değildir; havuz boyutu veritabanının ve uygulamanın kaldırabildiği kapasiteye göre belirlenmelidir.

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

Yüksek trafikli site yönetmek bir kere konfigürasyon yapıp bırakacağınız bir iş değil. Windows Server ve IIS birleşimi doğru kurgulandığında sağlam çalışır; fakat 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 ö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 ve 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, recycle olaylarını ve sıkıştırma seçeneklerini kontrol edin. Küçük dokunuşlarla ciddi kazanımlar elde edilebilir; fakat her kazanımı ölçümle doğrulayın. Ben production sunucusunda bir ayarı değiştirip grafiğe bakmadan kapatmayı eskiden “hızlı çözüm” sanıyordum. Şimdi önce değişikliği kaydediyor, sonra geri dönüş yolunu hazırlıyor ve en az bir trafik penceresi boyunca izliyorum.

Sık Sorulan Sorular

Yüksek trafikli bir site için Windows sunucuya kaç CPU ve ne kadar RAM ayırmalıyım?

Tek bir doğru rakam yoktur. Ağırlıklı olarak statik içerik sunan bir site ile her istekte veritabanına giden bir API aynı kaynakları tüketmez. 4 vCPU ve 8-16 GB RAM ölçüm için makul bir başlangıç olabilir; yoğun e-ticaret veya API iş yüklerinde 8 vCPU ve 16-32 GB RAM ile başlayıp p95 gecikme, hata oranı, bellek ve disk davranışını takip edin.

IIS Application Pool recycle ayarları nasıl yapılandırılmalı?

Yüksek trafikli uygulamalarda gereksiz sıklıkta recycle soğuk başlangıç, cache kaybı ve oturum sorunları yaratabilir. Idle Time-out’u sürekli trafik alan uygulamalarda 0 yapmayı, düzenli recycle gerekiyorsa düşük trafik saatlerine zamanlamayı değerlendirin. Private Memory Limit’i ise bellek sızıntısı kanıtı olmadan düşük belirlemeyin; recycle olaylarını WAS ve uygulama loglarıyla birlikte izleyin.

Tek güçlü Windows sunucu mu, birden fazla IIS düğümü mü tercih edilmeli?

Tek sunucu yönetimi daha basittir ve uygulamanın durumsuz olduğu küçük yapılarda yeterli olabilir. Arıza toleransı, bakım esnekliği veya dalgalı trafik önemliyse yük dengeleyici arkasında birden fazla IIS düğümü daha sağlıklıdır. Session, cache ve upload dosyalarını uygulama process’inden dışarı taşımanız gerekir; aksi halde düğüm eklemek yeni sorunlar üretebilir.

IIS üzerinde 503 Service Unavailable hataları nasıl azaltılır?

Önce IIS loglarındaki sc-status ve sc-substatus alanlarını, Event Viewer’daki WAS olaylarını ve App Pool durumunu kontrol edin. Kuyruk doluyorsa Queue Length’i artırmak kısa süreli tampon sağlayabilir; ancak worker process çökmesi, CPU sınırı, rapid-fail protection veya veritabanı gecikmesi çözülmeden kalıcı sonuç vermez. 503’ün alt durumunu bilmeden rastgele ayar değiştirmeyin.