Web Sunucusunda Runtime Ne Anlama Gelir?

Sesli Dinle — Makale

Web sunucusu bağlamında runtime, uygulama kodunu yürüten yazılım ortamıdır. Yorumlayıcıyı veya sanal makineyi, standart kitaplıkları, etkin uzantıları, süreç başlatma ayarlarını ve kodun gördüğü ortam değişkenlerini kapsayabilir.

Web sunucusu ile runtime aynı bileşen değildir. Web sunucusu, web isteklerini ve yanıtlarını taşıyan HTTP ile gelen isteği kabul eder; statik dosyayı doğrudan sunabilir veya dinamik isteği kodu çalıştıracak uygulama sürecine iletebilir. Bazı runtime ortamları kendi HTTP sunucusunu da başlatabildiğinden bu iki katman her mimaride ayrı bir ürün olmak zorunda değildir.

“Sunucu runtime” veya yalnız “runtime” etiketi tek başına belirsizdir. Bir panelde dil ve sürüm seçimini, bir hata iletisinde kodun yürütüldüğü ortamı, bir ölçüm ekranında işlem süresini, başka bir ekranda ise sürecin ne kadar zamandır açık olduğunu anlatabilir. Doğru anlam; ürün, birim, gösterilen değer ve ekranın amacı birlikte okunarak belirlenir.

Runtime Neleri Kapsar?

Bir runtime ortamının sınırı ürüne göre değişir; yine de aşağıdaki parçalar sık görülür:

• Kod yürütme motoru: Yorumlayıcı, sanal makine veya derlenmiş kodu çalıştıran temel motor.
• Standart kitaplık ve uzantılar: Dosya, ağ, şifreleme, veri tabanı sürücüsü veya dil özelliği sağlayan bileşenler.
• Süreç modeli: İşçi süreçleri, iş parçacıkları, olay döngüsü, kuyruklar ve eşzamanlı istek sınırları.
• Çalışma ayarları: Bellek ve süre sınırları, hata düzeyi, karakter kümesi, zaman dilimi ve ortam değişkenleri.
• Sürüm ve ikili uyumluluk: Dil özellikleri, yerel uzantılar ve uygulama bağımlılıklarıyla uyumluluğu belirleyen sürüm.

Programlama dili, geliştirmede hazır bileşenler ve bir uygulama yapısı sunan framework, paket yöneticisi ve uygulamanın kendi bağımlılıkları runtime ile ilişkili olsa da aynı şey değildir. Runtime kodu yürütür; framework geliştirme yapısını sunar, paket yöneticisi bağımlılıkları kurar, uygulama kodu ise iş kurallarını uygular.

İşletim sistemi de runtime ortamından ayrıdır. İşletim sistemi süreç, bellek, dosya ve ağ kaynaklarını sağlar; runtime bu kaynakların üzerinde uygulama kodunu yürütür. Container (kapsayıcı), uygulamayı gerekli dosya ve bağımlılıklarla paketleyebilir; süreç ve dosya görünümünü işletim sistemi özellikleriyle ayırabilir. Linux kapsayıcıları çalıştıkları ana sistemin çekirdeğini paylaşır. İçlerinde ayrı ve tam bir işletim sistemi kurulması gerekmez; kullanılan imaj yalnız uygulamanın ihtiyaç duyduğu bileşenleri içerebilir.

Web Sunucusu ile Runtime Arasındaki İstek Akışı

1. Web sunucusu bağlantıyı ve HTTP isteğini kabul eder; alan adı, yöntem ve yol gibi bilgileri değerlendirir.
2. İstek statik dosyaya karşılık geliyorsa dosyayı uygulama kodu çalıştırmadan gönderebilir.
3. Dinamik işlem gerekiyorsa isteği yapılandırılmış uygulama sürecine veya uygulama sunucusuna iletir.
4. Runtime uygulama kodunu yürütür; kod veri tabanı, önbellek veya başka hizmetlerle iletişim kurabilir.
5. Uygulama durum kodunu, başlıkları ve yanıt gövdesini üretir; ön katman bu yanıtı istemciye iletir.

Bu bağlantı farklı modellerle kurulabilir. CGI (Common Gateway Interface) geleneksel olarak her istek için ayrı süreç başlatabilir. FastCGI (Fast Common Gateway Interface) protokolü ise kalıcı süreçlere birden fazla istek ileterek süreç başlatma maliyetini azaltır. PHP-FPM (FastCGI Process Manager), farklı kullanıcı, ayar ve eşzamanlılık sınırlarına sahip süreç havuzları çalıştırabilir.

Başka bir modelde uygulama sunucusu kendi yerel HTTP portunu dinler; Nginx, Apache veya başka bir reverse proxy (ters proxy) isteği bu porta aktarır. Node.js ile yazılmış bir HTTP sunucusu veya ASP.NET Core uygulamasındaki Kestrel bu biçimde bağlantı dinleyebilir. Bu durumda ters proxy bağlantı yönetimi ve güvenlik sınırını, uygulama sunucusu ise kod yürütme ve uygulama yanıtını üstlenebilir.

HTTP, istemciyle sunucu arasındaki isteğin ve yanıtın anlamını tanımlar; kodun hangi dil, sürüm veya runtime ile yürütüleceğini belirlemez. Aynı HTTP yanıtı farklı runtime ortamlarıyla üretilebilir ve aynı runtime web isteği dışında komut satırı işi, kuyruk tüketicisi veya zamanlanmış görev de çalıştırabilir.

Yaygın Web Runtime Ortamları Nasıl Bağlanır?

Aşağıdaki örnekler tek zorunlu kurulum biçimi değildir; runtime ile istek kabul eden katmanın nasıl ayrılabildiğini gösterir.

Python tarafında WSGI, sunucunun uygulamayı bir istek alıp yanıt döndüren senkron bir çağrıyla çalıştırmasını tanımlar. Bu, sunucunun farklı işçi süreçleri veya iş parçacıklarıyla aynı anda birden fazla isteği işleyemeyeceği anlamına gelmez. ASGI ise uygulama ile sunucunun asenkron olay mesajlarıyla iletişim kurmasını sağlar ve WebSocket gibi uzun ömürlü, çift yönlü bağlantıları destekler. Bu arayüzler Python yorumlayıcısının kendisi değildir; uygulama sunucusunun runtime ortamındaki uygulamayı nasıl çağıracağını belirler.

IIS işlem içi barındırmada uygulamayı kendi işçi sürecinde IIS HTTP Server ile çalıştırır; bu modelde Kestrel kullanılmaz. İşlem dışı barındırmada ise istekleri ayrı süreçte çalışan Kestrel'e iletir.

Node.js, JavaScript kodunu olay döngüsüyle çalıştırır ve HTTP dinleyebilir; ancak olay döngüsünü uzun süren senkron işlemlerle engellemek diğer bağlantıların da beklemesine yol açabilir. Bir ürünün “asenkron” olması her kodun otomatik olarak hızlı veya engellemesiz olduğu anlamına gelmez.

Runtime, Kesintisiz Çalışma Süresi ve Yürütme Süresi

Uptime, yürütme süresi ve zaman dilimi runtime ortamından farklı sorulara cevap verir.

İşletim sistemi aylardır açıkken uygulama süreci birkaç dakika önce yeniden başlatılmış olabilir. Aynı şekilde süreç açık görünürken sağlık denetimi başarısız olabilir. Bu nedenle süreç yaşı, sistemin yeniden başlatılmadan çalıştığı süre ve ölçülen hizmet erişilebilirliği aynı değer olarak raporlanmamalıdır.

Süreç Modeli, Eşzamanlılık ve Kaynak Sınırları

Runtime sürümü kadar süreç modeli de önemlidir. PHP-FPM havuzunda static, dynamic veya ondemand süreç yönetimi seçilebilir; pm.max_children aynı anda işlenebilecek istek sayısına sınır koyar. Sınır dolduğunda istekler bekleyebilir veya ön katmandaki süre aşımı nedeniyle başarısız olabilir.

Node.js olay döngüsü ağ giriş-çıkışını verimli biçimde koordine edebilir, fakat uzun süren bir geri çağırım veya ağır hesaplama olay döngüsünü engeller. Python WSGI ve ASGI sunucularında ise işçi süreci, iş parçacığı, olay döngüsü ve bağlantı sınırları kullanılan sunucuya göre değişir. Yalnız dil adına bakarak eşzamanlılık kapasitesi çıkarılamaz.

Bellek sınırı, istek zaman aşımı, gövde boyutu ve kuyruk kapasitesi ters proxy, web sunucusu, uygulama sunucusu, runtime veya uygulama katmanlarının birkaçında birden tanımlanabilir. Fiili davranışı çoğu zaman ilk dolan ya da en kısa süre aşımına sahip katman belirler. 500, 502 veya 504 sonucu tek başına hatanın hangi katmanda olduğunu kanıtlamaz; ilgili günlükler ve zaman çizelgesi birlikte incelenmelidir.

Yeniden başlatma veya yeni süreç açılışından sonraki ilk istek; kodun ve kitaplıkların yüklenmesi, önbelleğin oluşması ya da bağlantı havuzlarının kurulması nedeniyle daha yavaş olabilir. Cold start (soğuk başlangıç) ile ısınmış durum ölçümlerini ayrı tutun; tek ilk istekten runtime sürümünün genel performansını çıkarmayın.

Runtime Etiketinin Bağlamı Nasıl Okunur?

• Sürüm biçimi: “PHP sürümü” veya “Node.js sürümü” gibi bir değer runtime ortamını gösterir.
• Süre birimi: “240 ms (milisaniye)” çoğunlukla tek isteğin veya görevin yürütme süresidir.
• Gün-saat sayacı: “Server runtime: 18 gün” sürecin ya da sistemin açık kalma süresi olabilir.
• Tarih-saat değeri: “Runtime timezone” runtime ortamının zaman dilimi ayarını anlatabilir.
• Hata bağlamı: “Runtime error” kod yürütülürken oluşan uygulama ya da ortam hatasını gösterebilir.

Etiketin yanında birim ve sürüm bulunmuyorsa ürünün resmi belgesini kontrol edin. “Runtime” sözcüğünü otomatik olarak kesintisiz çalışma süresi, performans değeri veya dil sürümü diye yorumlamak yanlış sonuca yol açabilir.

Runtime Sürümü Nasıl Değiştirilir?

Sürüm değişikliği; sözdizimi, framework, paketler, yerel uzantılar, veri tabanı sürücüleri ve çalışma ayarlarıyla uyumluluğu etkileyebilir. Yeni sürüm daha güncel olsa bile her uygulamada otomatik olarak daha hızlı veya sorunsuz çalışacağı varsayılamaz.

1. Uygulamanın ve kullanılan paketlerin desteklediği sürüm aralığını çıkarın; runtime üreticisinin güvenlik desteği bitiş tarihini de kontrol edin.
2. Etkin uzantıları, ortam değişkenlerini, süreç modelini ve kaynak sınırlarını kaydedin.
3. Dosya ve veri yedeğini alın; geri yükleme adımlarını ayrı test edin.
4. Aynı yapılandırmayı test ortamında kurup işlev, yük ve hata günlüğü denetimi yapın.
5. Üretim geçişinde sağlık denetimi, hata oranı, gecikme ve kaynak kullanımını izleyin.
6. Eski sürüme ve yapılandırmaya geri dönüş yolunu geçişten önce hazırlayın.

Hosting panelindeki sürüm seçimi yalnız ilgili alan adını, dizini veya süreç havuzunu etkileyebilir; tüm sunucunun runtime ortamını değiştirdiği varsayılmamalıdır. Seçim sonrası gerçek çalışan sürümü uygulamanın güvenilir tanılama yöntemiyle doğrulayın ve ayrıntılı sürüm bilgisini ziyaretçilere açık bırakmayın.

Günlüklerde Hata Katmanı Nasıl Ayrılır?

Web sunucusu erişim günlüğü istek yolunu, durum kodunu ve süreyi; web sunucusu hata günlüğü bağlantı veya iletim sorunlarını gösterebilir. Runtime ve uygulama günlükleri ise sözdizimi hatası, eksik paket, yakalanmamış istisna, bellek sınırı veya dış hizmet hatası gibi kod yürütme ayrıntılarını kaydedebilir. İşletim sistemi hizmet günlüğü de sürecin neden başlamadığını veya yeniden başlatıldığını gösterebilir.

Aynı isteği katmanlar arasında izlemek için istek kimliği veya ilişkilendirme kimliği kullanın. Sunucu saatlerinin eşitlendiğini doğrulayın ve kayıtlardaki zaman dilimi farklarını hesaba katın. Ayrıntılı hata iletisini ve yığın izini doğrudan ziyaretçiye göstermek yerine güvenli günlüğe yazın; ziyaretçiye genel hata yanıtı verin.

Runtime Sürecini Yeniden Başlatma

Runtime sürecini yeniden başlatmak normalde dosya veya veri tabanındaki kalıcı veriyi silmez. Buna karşılık bellekte tutulan oturum, önbellek, bellekteki kuyrukta tamamlanmamış iş veya açık bağlantı etkilenebilir. Yeniden başlatma davranışını süreç yöneticisi, uygulama ve trafik katmanıyla birlikte planlayın.

Uygulamanın Yanıt Verdiği Nasıl Doğrulanır?

Runtime sürümünü veya süreç durumunu görmek, belirli bir URL’nin o anda doğru yanıt verdiğini kanıtlamaz. Gerçek bir HTTP isteğiyle hedef sayfanın durum kodunu ve beklenen içeriği kontrol edin. Oturum açma veya veri tabanına erişme gibi gerekli işlemleri test hesabıyla ayrıca sınayın; ana sayfanın açılması bunların da çalıştığını göstermez. Uzun dönem erişilebilirliği ölçmek için tek bir istek sonucu yerine düzenli izleme verisi gerekir.