Metodolojiden bahsettik. Bu makalede HTTPS'yi test ediyoruz, ancak daha gerçekçi senaryolarda. Test için Let's Encrypt sertifikası alındı, Brotli sıkıştırması 11'de etkinleştirildi.
Bu sefer bir sunucunun VDS'ye veya standart işlemcili bir ana makineye sanal makine olarak dağıtılması senaryosunu yeniden oluşturmaya çalışacağız. Bu amaçla şu şekilde bir sınır belirlendi:
- %25 - ~ 1350 MHz frekansına eşdeğerdir
- %35 -1890MHz
- %41 - 2214 MHz
- %65 - 3510 MHz
Tek seferlik bağlantı sayısı 500'den 1, 3, 5, 7 ve 9'a düşürüldü,
Sonuçlar:
Gecikmeler:
HTTPD Araçları her bireysel istek için yeni bir kullanıcı oluşturduğundan, TTFB özellikle ayrı bir test olarak dahil edilmiştir. Bu test hala gerçeklikten oldukça kopuk çünkü kullanıcı yine de birkaç sayfayı tıklayacak ve gerçekte TTFP ana rolü oynayacak.
IIS sanal makinesinin ilk başlatılmasından sonraki ilk, genellikle ilk istek ortalama 120 ms sürer.
Sonraki tüm istekler 1.5 ms'lik bir TTFP gösterir. Apache ve Nginx bu konuda geride kalıyor. Kişisel olarak yazar bu testi en açıklayıcı test olarak görüyor ve kazananı yalnızca buna göre seçiyor.
IIS zaten sıkıştırılmış statik içeriği önbelleğe aldığından ve bu içeriğe her erişildiğinde onu sıkıştırmadığından sonuç şaşırtıcı değildir.
Müşteri başına harcanan süre
Performansı değerlendirmek için 1 tek bağlantıyla yapılan test yeterlidir.
Örneğin IIS, 5000 kullanıcıdan oluşan bir testi 40 saniyede tamamladı; bu da saniyede 123 istek demektir.
Aşağıdaki grafikler site içeriğinin tamamen aktarılmasına kadar geçen süreyi göstermektedir. Bu, belirli bir sürede tamamlanan isteklerin oranıdır. Bizim durumumuzda tüm isteklerin %80'i IIS'de 8 ms, Apache ve Nginx'te 4.5 ms'de işlendi ve Apache ve Nginx'te tüm isteklerin %8'i 98 milisaniyeye kadar bir sürede tamamlandı.
5000 isteğin işlendiği süre:
5000 isteğin işlendiği süre:
3.5 GHz CPU'lu ve 8 çekirdekli bir sanal makineniz varsa ne istediğinizi seçin. Bu testte tüm web sunucuları birbirine çok benzer. Aşağıda her bir ana bilgisayar için hangi web sunucusunun seçileceğinden bahsedeceğiz.
Biraz daha gerçekçi bir duruma gelince, tüm web sunucuları kafa kafaya gidiyor.
Üretilen:
Gecikmelerin eşzamanlı bağlantı sayısına göre grafiği. Daha yumuşak ve daha alçak olması daha iyidir. Son %2'lik kısım ise okunmaz hale getireceği için listelerden çıkarıldı.
Şimdi sunucunun sanal barındırmada barındırıldığı seçeneği ele alalım. 4 GHz'de 2.2 çekirdek ve 1.8 GHz'de bir çekirdek alalım.
Ölçeklendirme nasıl yapılır
Vakum triyotlarının, pentotların ve benzerlerinin akım-gerilim özelliklerinin neye benzediğini gördüyseniz, bu grafikler size tanıdık gelecektir. Yakalamaya çalıştığımız şey bu; doygunluk. Sınır, ne kadar çekirdek atarsanız atın, performans artışının fark edilmeyeceği zamandır.
Daha önce tüm zorluk, eğriyi mümkün olduğu kadar düz tutarak, tüm istekler için en düşük gecikme süresiyle isteklerin %98'ini işlemekti. Şimdi başka bir eğri oluşturarak her sunucu için en uygun çalışma noktasını bulacağız.
Bunu yapmak için Saniye başına istek (RPR) göstergesini ele alalım. Yatay frekanstır, dikey saniyede işlenen istek sayısıdır, çizgiler ise çekirdek sayısıdır.
Nginx'in istekleri birbiri ardına ne kadar iyi işlediğine ilişkin bir korelasyon gösterir. 8 çekirdek bu testte daha iyi performans gösteriyor.
Bu grafik, Nginx'in tek bir çekirdek üzerinde ne kadar iyi (çok değil) çalıştığını açıkça gösteriyor. Nginx'iniz varsa ve yalnızca statik olanları barındırıyorsanız çekirdek sayısını bire düşürmeyi düşünmelisiniz.
IIS, Chrome'daki DevTools'a göre en düşük TTFB'ye sahip olmasına rağmen Apache Foundation'ın stres testiyle ciddi bir mücadelede hem Nginx'e hem de Apache'ye kaybetmeyi başarıyor.
Grafiklerin tüm eğrilikleri demir kaplı olarak yeniden üretilir.
Bir tür sonuç:
Evet, Apache 1 ve 8 çekirdekte daha kötü çalışıyor ancak 4 çekirdekte biraz daha iyi çalışıyor.
Evet, 8 çekirdekli Nginx, 1 ve 4 çekirdekte istekleri birbiri ardına daha iyi işler ve çok sayıda bağlantı olduğunda daha kötü çalışır.
Evet, IIS, çok iş parçacıklı iş yükleri için 4 çekirdeği, tek iş parçacıklı iş yükleri için ise 8 çekirdeği tercih eder. Sonuçta IIS, tüm sunucular aynı seviyede olmasına rağmen yüksek yük altında 8 çekirdekte diğerlerinden biraz daha hızlıydı.
Bu bir ölçüm hatası değildir, buradaki hata +-1 ms'den fazla değildir. gecikmelerde ve RPR için saniyede +- 2-3 istekten fazla olmamalıdır.
8 çekirdeğin daha kötü performans gösterdiği sonuçlar hiç de şaşırtıcı değil; birçok çekirdek ve SMT/Hyperthreading, tüm hattı tamamlamamız gereken bir zaman çerçevemiz varsa performansı büyük ölçüde düşürür.
Kaynak: habr.com