Web Sunucusu ve Komut Dosyası Motorunun Ayrılması – Blog Yazma – Web Tasarımı Yapımı – Web Tasarımı YouTube Videosu Yapımı – Web Sitesi Tasarlama Fiyatları
Web Sunucusu ve Komut Dosyası Motorunun Ayrılması
Mimarisinin evrimi, Web sunucusunun komut dosyası oluşturma motorundan ayrılmasıdır. İlki, HTTP isteklerini alır, statik HTML sayfaları gönderir ve dinamik olarak hesaplanan sayfalar için istekleri komut dosyası motoruna yönlendirir; ikincisi, yanıt sayfasını üretmek için gerekli verileri almak için veritabanına istekler üretebilen dinamik sayfa hesaplaması için sunucu tarafı programları yürütür. Klonlama, gösterilen yapılandırmayı elde ederek Web sunucusuna ve program yürütme motoruna ayrı ayrı uygulanabilir.
Bu ayrım, ölçeklenebilirliği ve hata toleransını daha da iyileştirir, çünkü artık Web sunucusu ve komut dosyası motoru bağımsız olarak çoğaltılabilir. Ayırma, biri HTTP sunucularında ve diğeri komut dosyası motorlarında olmak üzere iki düzey yük dengeleme sunar.
Normalde, program yürütme motorundaki işleme, HTTP sunucusununkinden çok daha ağırdır ve bu nedenle, iyi dengelenmiş bir yapılandırma, komut dosyası motorları için Web sunucularından daha fazla makine gerektirebilir. İki işlevi ayırmak ve bağımsız olarak kümelemek, ana bilgisayar sayısının optimize edilmesini sağlar.
Teknik açıdan bakıldığında, motor ve Web sunucusunun ayrılması, iki bileşen arasındaki iletişim protokolünün uygulanmasını etkiler; ayırmanın getirdiği iletişim yükü, yatay klonlamadan kaynaklanan performans artışıyla telafi edilmelidir.
Uygulama Sunucusu ile Yapılandırma
Orta katman, özellikleri önceden tartışılmış bir uygulama sunucusuyla genişletilerek mimari daha ölçeklenebilir ve modüler hale getirilebilir. Web sunucusundan veritabanı sunucusuna kadar tüm çeşitli katmanların çoğaltma ve kümelemeyi kullandığı uygulama sunucusu mimarisinin bir örneğini gösterir.
Uygulama sunucularının avantajı, iş mantığının, paylaşılan kaynakları, şeffaf nesne düzeyinde çoğaltmayı, yük dengelemeyi ve yük devretmeyi yöneten özel bir alt katmanda merkezileştirilmesidir.
Önceki mimarilerden farklı olarak, uygulama sunucusu içindeki paralellik dinamiktir: uygulama sunucusu, gerçek trafiğe dayalı olarak, çalışma zamanında her bir iş bileşenine tahsis edilecek süreçlerin sayısına karar verir. Bu şekilde, aynı ana bilgisayar üzerinde daha fazla uygulama bir arada bulunabilir, çünkü uygulama sunucusu onların çekişmesini düzenleyerek daha fazla iş yükü yaşayan uygulamaya daha fazla kaynak verir.
Mimarisi maksimum konfigürasyon esnekliği sağlar, çünkü her fonksiyon bağımsız olarak kopyalanabilen ayrı bir fiziksel katmana eşlenir ve neredeyse sınırsız bir ölçeklenebilirlik sağlar, çünkü her katmana bileşenler eklenebilir, böylece genel denge korunur.
Uygulama sunucusu mimarisinin bir başka yararı da, kullanıldıkları bağlamdan bağımsız olan yeniden kullanılabilir iş nesnelerinin geliştirilmesini desteklemesidir. Uygulama sunucusunda barındırılan nesneler, orta katmandaki sayfa şablonları ve ayrıca kuruluş genelinde dağıtılan Web dışı uygulamalar, örneğin bağımsız Java uygulamaları tarafından çağrılabilir.
Başka bir deyişle, uygulama sunucusundaki iş nesneleri, kurumsal uygulama entegrasyonu için bir platformdur; kurumsal çapta iş işlevleri, uygulama sunucusunda geliştirilebilir ve dağıtılabilir ve ardından her tür istemci tarafından tutarlı bir şekilde kullanılabilir.
Heterojen istemcilerin farklı güvenlik gereksinimleriyle başa çıkmak için, uygulama sunucusu ayrı bir askerden arındırılmış bölgeye (DMZ2 etiketli) yerleştirilebilir.
İnternet istemcileri, uygulama sunucusuna DMZ aracılığıyla erişir ve iki güvenlik duvarını geçmeleri gerekir; Kurumsal uygulamalara Sanal Özel Ağ gibi güvenli bir ağ üzerinden erişen intranet veya extranet istemcileri gibi daha güvenilir istemciler, ikinci askerden arındırılmış bölge içinde yaşayabilir, uygulama sunucusuna ayrıcalıklı erişime sahip olabilir, ancak yine de sunucudan ayrı kalabilir.
Http Nedir
Https Nedir
Http güvenli mi
Https protokolü Nedir
http:// yerine https://
Performansı Test Etme ve Geliştirme Teknikleri
Bu mimari galerisinin sonunda ve veri yoğun bir Web uygulamasının çeşitli özelliklerinin nasıl uygulanacağına ilişkin tartışmaya girmeden önce, uygulama mimarisinin tasarımında belirli ve çok önemli bir konuyu yakınlaştırıyoruz: yöntemler ve performansı test etmek ve geliştirmek için araçlar.
İş Yükünü Tahmin Etme
Mimariyi boyutlandırmak ve performansını doğrulamak için başlangıç noktası, tipik olarak istemcilerin yapacağı sayfa isteklerinin sayısını ve türünü ve bu istekleri kabul edilebilir şekilde yanıtlamak için gereken yanıt süresini tahmin etmek anlamına gelen performans gereksinimlerinin belirtilmesidir. İş yükünü tahmin etmek kesin bir disiplin değildir ve B2B ve intranet uygulamalarından İnternet kullanıcılarına sunulan B2C uygulamalarına geçildiğinde hata payı büyük ölçüde artar.
B2B veya kurumsal uygulamalar için, kullanıcı sayısı iyi bir tahminle belirlenebilir ve gereksinim analizi sırasında ortaya çıkan kullanım senaryoları, bu sayıların beklenen sayfa isteklerinin mantıklı bir tahminine dönüştürülmesine izin verir.
Örneğin, bir kullanım durumu günlük 10.000 kullanıcıdan oluşan bir kullanıcı grubunun ortalama 30 sayfa isteği göndererek bir site görünümüne eriştiğini belirtiyorsa, günlük 30×10.000=300.000 sayfa erişim sayısı kabaca alınabilir. site görünümü için iş yükünün tahmini. Çalışan sayısında veya kullanım örneğinde açıklanan iş akışında önemli bir değişiklik olmadıkça, bu tür bir sayı açıkça dalgalanacaktır, ancak önemli ölçüde değildir.
Tersine, bir B2C uygulaması çok daha az tahmin edilebilirdir, çünkü isabet sayısı uygulamanın başarısına bağlıdır, bu önceden tahmin edilmesi zor bir faktördür. Bu durumda, pazarlama analizi, satış tahminleri ve rakip incelemeleri dahil olmak üzere uygulamanın iş gereksinimleri, beklenen müşteri sayısını ve dolayısıyla talep hacimlerini tahmin etmeye yardımcı olabilir.
Her durumda, iş yükü bir dizi parametre aracılığıyla karakterize edilmelidir:
- Sayfa isteklerinin sayısı: örneğin, saniye başına sayfa olarak ifade edilen, istemciler tarafından gönderilen isteklerin ortalama ve en yüksek sayısı. Bu sayı, istemci tarafından algılandığı şekliyle uygulamanın verimini ifade eder.
- Eşzamanlı kullanıcı sayısı: Bu sayı, uygulamaya aynı anda erişecek ortalama ve maksimum kullanıcı sayısının tahminini ifade ettiğinden, sayfa istek sayısından farklıdır. Eşzamanlı kullanıcı sayısı, özellikle iş ve veri katmanında kuyrukların oluşabileceği uygulama arka ucunu etkiler.
- Yanıt süresi: İstemcinin yanıt için beklemesi gereken maksimum saniye sayısı. İdeal olarak, yanıt süresi kullanıcının düşünme süresini (3 saniye diyelim) aşmamalı ve en yoğun koşullarda nispeten kararlı olmalıdır. Tepki süresi, ilk bayta (TTFB) ve son bayta (TTLB) kadar olan sürede daha da ayırt edilebilir.
- İlki, arka uç işleme performansının bir göstergesini verir, çünkü tüm sayfanın iletiminden kaynaklanan herhangi bir ağ gecikmesini yok sayar; ikincisi müşteri için daha önemlidir, çünkü tam yanıtı almak için gereken süreyi ölçer.
- İstek karışımı: Bir uygulamanın farklı karmaşıklığa sahip birçok farklı sayfadan oluştuğu göz önüne alındığında, saniyedeki çıplak istek sayısı yükü karakterize etmek için yetersizdir. Performans testini daha güvenilir hale getirmek için kullanıcının davranışını tahmin etmek ve ardından gerçekle eşleşen yapay bir iş yükü oluşturmak gerekir.
- İstek karışımı, her uygulama sayfasıyla, kullanıcının ortalama bir etkileşimli oturumda sayfaya erişme olasılığını gösteren bir “ağırlık” ilişkilendirilerek ifade edilebilir. Sayfa olasılıkları, gerçekçi iş yükleri oluşturmak için test oturumları sırasında kullanılabilir.
