Windows server 2022 IIS

Bilgim yok, ilgilendiğim bir alan değil ama 2022 dokümantasyonunda değişenleri yüzeysel okumuştum. Bence OS ve IIS doc.una odaklanın core temelinde değişiklikler olabilir, yazdıklarınız da bunu canlandırıyor kafada, uzun vade de OS güncellemelerinde bu tür şeyler oluyor.
Kodlayıcı siz değilseniz aslında sizin işiniz değil, onların okuyup bulması varsa güncellemesi gerekli ama öyle insan az bazen bulup bakın değişiklikler şurada yazıyor ona göre analiz edin diye zorlamak gerekiyor dünyalıyı.
Mesela yeni, temiz yazılmış bir php de sorun yoksa, sorun sizin sisteminiz kaynaklı değildir, malumunuz.
Umarım konuya odaklı deneyim etmiş biri çıkar. 

İbrahim bey verdiğiniz cevap için teşekkür ederim. Denemek için sıfırdan wordpress son sürümünü kurdum.. Web sitesinin çalıştığı IIS Poolde Managed Pipeline Modu integrated da iken web sitesinin ilk açılış süreleri uzun sürüyor web site açıldıktan sonra hızlanıyor. belli bir süre tekrar web sitene girmeye çalışınca tekrar ilk açılış yavaşlıyor. integrated modu classic yapınca, ilk açılış da daha sonradan girişlerde hızlı bir şekilde açılıyor.  Sormak istediğim konu server 2019 de web siteleri integrated modunda çalışıyordu sorun yoktu, siteleri server 2022 ye taşıdım ve orada da integrated modunu aktif ettim, böyle sorunlar yaşanıyor.  Belki bu konuda bilgisi olan arkadaşlar olur diye danışmak istedim.

Integrated vs Classic Pipeline Mode

Integrated Mode (Server 2022'de)

• ASP.NET ve IIS bileşenlerini tek bir işlem hattında birleştirir.

• Modern .NET uygulamaları için idealdir.

• Ancak: PHP uygulamaları bu modda beklenmedik davranışlar sergileyebilir çünkü PHP, ASP.NET pipeline’ına tam entegre değildir.

Classic Mode

• ASP.NET requestlerini ayrı bir işlem hattında işler.

• PHP gibi non-.NET uygulamalarla daha uyumlu çalışır.

• Bu nedenle ilk açılış süresi ve response time daha iyi olabilir.

🎯 Sorunun Temel Sebebi

• Integrated mode altında, iisexpress veya FastCGI aracılığıyla çalışan PHP, request pipeline’ın ilk yüklenmesinde bekleme yaratabiliyor.

• Özellikle IIS üzerinde çalışan PHP (örneğin WordPress) için:

  • First request (ilk istek) sırasında PHP engine ve PHP modül ilk defa ayağa kalkıyor.

  • Bu işlem memory'den temizlendiyse veya pool idle timeout’a düştüyse, tekrar yükleniyor → yavaş açılış.

🧪 Neden Server 2019’da Sorun Yoktu?

Server 2019 üzerindeki FastCGI modül veya PHP sürümü konfigürasyonu muhtemelen daha farklıydı:

• Idle timeout, pool recycling gibi ayarlar farklı olabilir.

• 2022’de gelen FastCGI veya IIS update'leri bu davranışı etkiliyor olabilir.

🔧 Çözüm Önerileri

1. Application Pool Idle Timeout Ayarı

• Varsayılan: 20 dakika

• Eğer pool kendini kapatıyorsa her açılışta yüklenme yavaş olur.

  • IIS Manager > Application Pools > Pool’a sağ tık > Advanced Settings:

    • Idle Time-out (minutes) → 0 yaparak kapanmayı engelleyin.

    • Veya 30-60 dakikaya çıkarın.

2. AlwaysRunning & Auto-Start Ayarları

• Application Pool:

  • Start Mode → AlwaysRunning

• Application Settings:

  • Preload Enabled → True

Bu ayarlar ile Application Pool durmaz ve ısınmış halde bekler.

3. FastCGI Ayarlarını Kontrol Edin

IIS Manager > FastCGI Settings > PHP versiyonuna sağ tık > Edit:

• InstanceMaxRequests → 10000

• Activity Timeout / Request Timeout → 600 gibi yüksek değer verin

• IdleTimeout → 300 veya daha fazla yapın

4. PHP OPcache Ayarları

php.ini içinde OPcache aktif mi?

OPcache yoksa her sayfa tekrar derlenir ve açılış yavaşlar.

🔁 Classic Mode'da Daha İyi Performans Almanızın Nedeni

Classic Mode, ASP.NET pipeline’ına PHP’yi sokmadan, daha doğrudan işlem yapar. Bu nedenle özellikle PHP tabanlı web uygulamaları (WordPress gibi) için genellikle daha stabildir.

✅ Öneri

Eğer sadece WordPress gibi PHP tabanlı siteler barındırıyorsanız, Classic modunu kullanmak daha sağlıklı ve performanslı olacaktır.
ASP.NET uygulamaları için ayrı pool’larda Integrated modunu yine kullanabilirsiniz.

İbrahim bey yardımlarınız için teşekkür ederim, aydınlatıcı bir yazı olmuş...

Merhaba, IIS üzerinde kullanılan pipeline mode temel olarak aslında sizin yazılımınız ile ilgili bir durumdur. Yani yazılımı geliştiren dev arkadaşlara biz bunu sorarız, ona göre site tanımlar ve teslim ederiz (Büyük kurumlarda yetki ayrılığı olduğu için IIS' i full managed edemezler veya etmezler, infra ekibinden isterler). Özetle infra ekibi aslında pipeline mode için yorum yapmaz. Ancak anladığım kadarı ile burada hem yazılımı siz yapmadınız hem de böyle bir ayrım yok. O zaman öncelikle kullandığınız yazılım için en uygun pipeline mode' hangisi onu öğrenmeniz gerekli.

Ama bilenen fark şu, classic mode, eski nesil yazılımlar içindir, integrated mode ise yeni nesil yazılımlar içindir. Özetle eğer eski sistem integrated mode' da çalışıyor ise onu bir daha classic mode' a çevirmeniz tavsiye edilen bir yöntem değildir.

Bu sorunu anlamak için biraz yazılım bilmek ve debug log açmak veya yazılım bilmiyorsanız örnek fiddler gibi bir ürün ile gecikmenin nedenini kontrol edebilirsiniz. Sonuçta OS versiyonunda da TLS başta güncellemeler olduğu için konu bir güvenlik sorgulaması da olabilir. Ayrıca sizin uygulama örnek .net 4.5 için uygun ancak güncel OS 4.8 ve üstü çalışıyor ise, burada ek güvenlik özellikleri var, bu nedenle aslında integrated olarak çalışan bu uygulama yeni OS ve .net sürümü ile gelen "security tightening" başlığına takılıyor olabilir. Bu nedenle klasik pipeline' a çekince desteği olduğu için yine çalışıyordur ve daha hızlı çalışması klasik pipeline' ın daha basit, korumasız bir mekanizma olmasından kaynaklıdır.

Özetle bu işin çözümü yazılımcıda bitiyor, her bir soru için debug açtırır ise örneğin kod' un memory random işlemine mi takıldığına kadar detay görebilir. Eğer yazılımcınız yok veya bu yazılımı geliştiren ortada değil ise bir uzmana danışabilir veya uzman da yok ise Azure Appin veya dynatrace ve benzeri APM ürünlerinin demoları ile bu bilgiyi alabilirsiniz.

Hakan bey, verdiğiniz bilgiler için teşekkür ederim. Anlattıklarınızdan bazı fikirler oluştu.

Rica ederim, iyi çalışmalar.