Ger\u00e7ek hayatta y\u00fcksek trafikli site y\u00f6neten herkes bilir; sorun \u00e7o\u011fu zaman koddan de\u011fil altyap\u0131dan patlar. \u00d6zellikle bir windows sunucu \u00fczerinde IIS ile yay\u0131n yap\u0131yorsan\u0131z, birka\u00e7 yanl\u0131\u015f varsay\u0131mla dakikalar i\u00e7inde CPU tavan, bellek s\u0131z\u0131nt\u0131s\u0131, kuyruk dolmas\u0131 ve zaman a\u015f\u0131m\u0131 hatalar\u0131yla u\u011fra\u015fabilirsiniz. Do\u011fru planlanm\u0131\u015f bir IIS yap\u0131land\u0131rma ise ayn\u0131 donan\u0131mda \u00e7ok daha fazla iste\u011fi stabil \u015fekilde kar\u015f\u0131layabilir.<\/p>\n
Bu rehberde odak noktas\u0131, \u00fcretim ortam\u0131nda \u00e7al\u0131\u015fan y\u00fcksek trafikli site senaryolar\u0131 olacak. Tek bir blog de\u011fil; kampanya d\u00f6neminde saniyede y\u00fczlerce iste\u011fe \u00e7\u0131kan e-ticaret, yo\u011fun API \u00e7a\u011fr\u0131lar\u0131 veya y\u00fcksek say\u0131da e\u015fzamanl\u0131 oturuma sahip kurumsal uygulamalar gibi bask\u0131 alt\u0131nda kalan sistemlerden bahsediyoruz. T\u00fcm \u00f6rnekler windows hosting altyap\u0131s\u0131nda, Windows Server + IIS kombinasyonu \u00fczerinden ilerleyecek.<\/p>\n
Buradaki ad\u0131mlar\u0131n her biri, g\u00fcn\u00fcn birinde “neden yava\u015flad\u0131k?” sorusunu daha az sorman\u0131z\u0131 sa\u011flamak i\u00e7in tasarland\u0131. Yap\u0131land\u0131rmay\u0131 ad\u0131m ad\u0131m ele alal\u0131m.<\/p>\n
Performans ayarlar\u0131na girmeden \u00f6nce, mimariyi netle\u015ftirmek gerekiyor. Y\u00fcksek trafikli site kavram\u0131, tek bir windows sunucu ile \u00e7\u00f6z\u00fclemeyecek kadar yo\u011fun olabilir. Bu y\u00fczden \u00f6ncelikle dikey ve yatay \u00f6l\u00e7ekleme se\u00e7eneklerini masaya koymal\u0131s\u0131n\u0131z.<\/p>\n
\u0130lk soru genelde \u015fu olur: “Ka\u00e7 CPU, ne kadar RAM yeter?” Cevap, uygulaman\u0131n do\u011fas\u0131na ba\u011fl\u0131, ama baz\u0131 pratik s\u0131n\u0131rlar var. IIS taraf\u0131nda CPU \u00e7ekirdek say\u0131s\u0131, e\u015fzamanl\u0131 istekleri kar\u015f\u0131lama kapasitesini do\u011frudan etkiler. Haf\u0131za ise hem .NET runtime hem de cache kullan\u0131m\u0131 i\u00e7in kritik. Ba\u015flang\u0131\u00e7 i\u00e7in kabaca \u015fu yakla\u015f\u0131m mant\u0131kl\u0131d\u0131r:<\/p>\n
Depolama taraf\u0131nda IOPS de\u011feri ihmal edilmemeli. Log dosyalar\u0131, temp dosyalar, cache ve statik i\u00e7erikler ayn\u0131 disk \u00fczerinde yar\u0131\u015f\u0131yorsa, en g\u00fc\u00e7l\u00fc CPU bile sizi kurtarmaz. M\u00fcmk\u00fcnse loglar ve i\u00e7erik dosyalar\u0131 i\u00e7in ayr\u0131 diskler planlay\u0131n.<\/p>\n
Y\u00fcksek trafikli site mimarisinde, IIS genellikle do\u011frudan internete a\u00e7\u0131lmaz. Tipik olarak \u00f6ne bir ters vekil (reverse proxy) veya donan\u0131msal load balancer gelir, arka tarafta ise bir veya birden fazla windows sunucu \u00fczerinde IIS worker s\u00fcre\u00e7leri \u00e7al\u0131\u015f\u0131r. Uygulama sunucusunun do\u011frudan d\u0131\u015f d\u00fcnyaya a\u00e7\u0131k olmamas\u0131, hem g\u00fcvenlik hem de performans a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck avantaj sa\u011flar.<\/p>\n
E\u011fer modern bir bulut veya sanal sunucu altyap\u0131s\u0131 kullan\u0131yorsan\u0131z, \u00f6rne\u011fin VPS.TC \u00fczerindeki VPS<\/a> ya da bulut sunucu<\/a> servisleriyle, ayn\u0131 datacenter i\u00e7inde y\u00fck dengeleyici ve web sunucular\u0131n\u0131 ayr\u0131 makinelerde konumland\u0131rmak olduk\u00e7a pratik hale geliyor. B\u00f6ylece trafik dalgaland\u0131\u011f\u0131nda ek IIS d\u00fc\u011f\u00fcmleri ekleyip yatayda \u00f6l\u00e7ekleyebilirsiniz.<\/p>\n \u015eimdi windows sunucu taraf\u0131nda kritik IIS yap\u0131land\u0131rma ba\u015fl\u0131klar\u0131na ge\u00e7elim. Burada her ayar, do\u011frudan \u00fcretim ortam\u0131nda hissetti\u011finiz metrikleri etkiler: cevap s\u00fcresi, hata oran\u0131, CPU kullan\u0131m\u0131, bellek t\u00fcketimi ve kuyruk dolma olaylar\u0131 gibi.<\/p>\n Her y\u00fcksek trafikli site i\u00e7in ilk durak, Application Pool ayarlar\u0131d\u0131r. Varsay\u0131lan ayarlarla gelen bir\u00e7ok pool, geli\u015ftirme ortam\u0131nda idare eder ama \u00fcretim i\u00e7in agresif say\u0131labilecek geri d\u00f6n\u00fc\u015f\u00fcm (recycle) davran\u0131\u015flar\u0131na sahiptir. A\u015fa\u011f\u0131daki ilkeleri uygulamak, istikrar\u0131 ciddi bi\u00e7imde iyile\u015ftirir:<\/p>\n Bir\u00e7ok ekipte yap\u0131lan hata, memory leak korkusuyla \u00e7ok agresif recycle ayarlar\u0131 yapmak. Bunun sonucu, kullan\u0131c\u0131lar\u0131n ortas\u0131nda session kayb\u0131, uzun yan\u0131t s\u00fcreleri ve 503 hatalar\u0131 olur. Sorunu saklam\u0131\u015f olursunuz ama \u00e7\u00f6zmemi\u015f.<\/p>\n App Pool alt\u0131nda \u00e7al\u0131\u015fan w3wp s\u00fcre\u00e7lerinin say\u0131s\u0131 (“Maximum Worker Processes” veya web garden) ve HTTP.SYS kuyru\u011fu (queue length) y\u00fcksek trafikte belirleyicidir. \u00c7o\u011fu senaryoda tek worker process idealdir; state managment, cache ve connection pool payla\u015f\u0131m\u0131 a\u00e7\u0131s\u0131ndan daha \u00f6ng\u00f6r\u00fclebilir davran\u0131r.<\/p>\n Queue Length varsay\u0131lan\u0131 genellikle 1000 civar\u0131ndad\u0131r. \u00c7ok y\u00fcksek trafikli bir windows hosting ortam\u0131nda bu kuyruk dolarsa, 503 hatalar\u0131 almaya ba\u015flars\u0131n\u0131z. Kuyruk kapasitesini art\u0131rmak i\u00e7in Application Pool geli\u015fmi\u015f ayarlar\u0131ndan “Queue Length” de\u011ferini, test sonu\u00e7lar\u0131n\u0131za g\u00f6re 5000 veya 10000 seviyelerine \u00e7ekebilirsiniz. Ancak bu ayar\u0131 art\u0131rmak, sorunu \u00e7\u00f6zmez; sadece semptomu geciktirir. Kuyruk neden doluyor, onu da izlemek gerekir.<\/p>\n Basit g\u00f6r\u00fcnen ama en y\u00fcksek kazan\u0131m sa\u011flayan ayarlardan biri, HTTP s\u0131k\u0131\u015ft\u0131rma ve statik dosya optimizasyonudur. Y\u00fcksek trafikli site \u00e7o\u011funlukla ayn\u0131 JS, CSS, g\u00f6rsel ve font dosyalar\u0131n\u0131 tekrar tekrar servis eder. IIS \u00fczerinde a\u015fa\u011f\u0131dakileri etkinle\u015ftirmek iyi bir ba\u015flang\u0131\u00e7t\u0131r:<\/p>\n Bu ayarlar, do\u011frudan bant geni\u015fli\u011fi ve cevap s\u00fcresi \u00fczerinde etkilidir. Basit\u00e7e s\u00f6ylemek gerekirse; ayn\u0131 donan\u0131mla daha fazla kullan\u0131c\u0131ya hizmet vermi\u015f olursunuz.<\/p>\n \u00c7o\u011fu proje, web.config i\u00e7ine rastgele eklenen ayarlarla y\u0131llarca ya\u015far. Y\u00fcksek trafik s\u00f6z konusu oldu\u011funda, bu dosya art\u0131k performans arac\u0131 haline gelir. \u00d6zellikle ASP.NET uygulamalar\u0131 i\u00e7in a\u015fa\u011f\u0131daki ba\u015fl\u0131klara bakmak \u015fart.<\/p>\n Geli\u015ftirme s\u00fcrecinde a\u00e7\u0131k duran ayr\u0131nt\u0131l\u0131 hata sayfalar\u0131, tracing mekanizmalar\u0131 ve verbose log ayarlar\u0131, \u00fcretimde ciddi y\u00fck olu\u015fturur. Y\u00fcksek trafikli site i\u00e7in a\u015fa\u011f\u0131daki pratikleri uygulay\u0131n:<\/p>\n Loglar\u0131 merkezi sisteme g\u00f6ndermek (ELK, Splunk, Azure Application Insights vb.) genellikle daha \u00f6l\u00e7eklenebilir bir yakla\u015f\u0131m. Ama hangi \u00e7\u00f6z\u00fcm\u00fc se\u00e7erseniz se\u00e7in, synchronous dosya yaz\u0131m\u0131ndan ka\u00e7\u0131n\u0131n.<\/p>\n Y\u00fcksek trafikli bir API veya web uygulamas\u0131nda, upstream sistemlere (veritaban\u0131, cache, \u00fc\u00e7\u00fcnc\u00fc parti servisler) a\u00e7\u0131lan ba\u011flant\u0131 say\u0131s\u0131, b\u00fct\u00fcn sistemi kilitleyebilir. web.config i\u00e7inde connection string ayarlar\u0131n\u0131, connection pool parametrelerini ve HTTP timeout de\u011ferlerini g\u00f6zden ge\u00e7irmek gerekir.<\/p>\n \u00d6rne\u011fin SQL Server i\u00e7in connection pool ayarlar\u0131n\u0131 optimize etmek, IIS taraf\u0131nda thread starvation sorunlar\u0131n\u0131 azalt\u0131r. Her iste\u011fin uzun s\u00fcren bir veritaban\u0131 \u00e7a\u011fr\u0131s\u0131nda bekledi\u011fi bir senaryoda, IIS taraf\u0131ndaki her optimizasyon s\u0131n\u0131rl\u0131 kal\u0131r.<\/p>\n Tek bir windows sunucu, bir noktaya kadar i\u015fi ta\u015f\u0131r. \u00d6zellikle CPU kullan\u0131m\u0131n\u0131z s\u00fcrekli %70-80 seviyesinde geziyorsa ve dikeyde (daha g\u00fc\u00e7l\u00fc makine) b\u00fcy\u00fcmek maliyetli hale geldiyse, yatay \u00f6l\u00e7eklemeye ge\u00e7me zaman\u0131 gelir. IIS bu noktada iki farkl\u0131 yakla\u015f\u0131mla \u00f6ne \u00e7\u0131kar.<\/p>\n En klasik y\u00f6ntem, ayn\u0131 uygulamay\u0131 birden fazla windows sunucu \u00fczerine kurup, \u00f6nlerine bir y\u00fck dengeleyici (load balancer) koymakt\u0131r. Bu, ister donan\u0131msal load balancer isterse yaz\u0131l\u0131msal bir reverse proxy olsun, mant\u0131k ayn\u0131d\u0131r: gelen istekler farkl\u0131 IIS d\u00fc\u011f\u00fcmlerine da\u011f\u0131t\u0131l\u0131r.<\/p>\n Burada kritik soru \u015fudur: Oturum (session) y\u00f6netimi nas\u0131l? E\u011fer session bilgisi bellekte tutuluyorsa ve sticky session (client ayn\u0131 node a y\u00f6nlendirilir) kullanm\u0131yorsan\u0131z, kullan\u0131c\u0131 deneyimi bozulur. Daha sa\u011fl\u0131kl\u0131 yakla\u015f\u0131m, session bilgisini d\u0131\u015far\u0131 almakt\u0131r: Redis, SQL Server veya state server gibi. B\u00f6ylece herhangi bir windows sunucu iste\u011fi cevaplayabilir.<\/p>\n Cache, session, kullan\u0131c\u0131 durumu gibi veriler uygulama sunucusunun belle\u011finde tutulduk\u00e7a, yatayda geni\u015flemek zorla\u015f\u0131r. Y\u00fcksek trafikli site mimarisinde s\u0131k\u00e7a yap\u0131lan iyile\u015ftirmeler \u015funlard\u0131r:<\/p>\nY\u00fcksek trafikli senaryolar i\u00e7in temel IIS yap\u0131land\u0131rma ad\u0131mlar\u0131<\/h2>\n
Application Pool mimarisini do\u011fru kurgulamak<\/h3>\n
\n
Worker process ve queue length ayarlar\u0131<\/h3>\n
HTTP s\u0131k\u0131\u015ft\u0131rma ve statik i\u00e7erik optimizasyonu<\/h3>\n
\n
web.config ve makine d\u00fczeyi ayarlarda dikkat edilmesi gerekenler<\/h2>\n
CustomErrors, tracing ve logging davran\u0131\u015flar\u0131<\/h3>\n
\n
Connection limitleri ve timeout de\u011ferleri<\/h3>\n
Windows hosting ortam\u0131nda \u00f6l\u00e7eklenebilirlik ve y\u00fck dengeleme stratejileri<\/h2>\n
Uygulama sunucular\u0131n\u0131 \u00e7o\u011faltmak<\/h3>\n
Uygulama durumunu d\u0131\u015f sistemlere ta\u015f\u0131mak<\/h3>\n