Metodika haqqında məlumat verdik maddədə, bu dəfə HTTPS-in daha realistik ssenarilərdə testini edirik. Test üçün Let’s Encrypt sertifikatı alındı, Brotli sıxılması 11-də aktiv edildi.
Bu dəfə standart prosessorlu hostda VDS üzərində serverin yerləşdirmə ssenarisini təkrar etməyə çalışacağıq. Bunun üçün limit qoyuldu:
- 25% — Təxminən 1350MHz frekansında
- 35% - 1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
Eyni anda olan bağlantılar sayı 500-dən 1, 3, 5, 7 və 9-a enib
birləşdirərək yaradılacaq.
Gecikmələr:
TTFB ayrıca test kimi verilib, çünki HTTPD Tools hər ayrı istehsal üçün yeni istifadəçi yaradır. Bu test hələ də reallıqdan xeyli uzaqdadır, çünki istifadəçi bir neçə səhifəyə klikləyəcək, reallıqda TTFP əsas rol oynayacaq.
İlk başlanan IIS virtual maşından sonra ilk tələb ortalama 120 ms-də işləyir.
Sonrakı bütün tələbələr 1.5 ms TTFP göstərir. Apache və Nginx bu barədə geri qalır. Şəxsi olaraq, müəllif bu testi ən göstərici hesab edir və yalnız buna görə qalib seçərdi.
Nəticə gözlənilməz deyil, çünki IIS artıq sıxılmış statik məzmunu öncə saxlayır və ona müraciət edildikdə hər dəfə yenidən sıxmır.
Bir müştəri üçün sərf olunan vaxt
Performansı qiymətləndirmək üçün tək bir eyni anda bağlantı ilə test kifayətdir.
Məsələn, IIS 5000 istifadəçidən ibarət testi 40 saniyədə tamamladı, bu da 123 tələb saniyədədir.
Aşağıdakı qrafiklər saytın tam məzmununun ötürülməsinə qədər vaxtı göstərir. Bu, müəyyən bir zamanda yerinə yetirilən tələblərin hissəsidir. Bu halda IIS-də bütün tələblərin 80%-i 8 ms-də, Apache və Nginx-də isə 4.5 ms-də işlənmişdir, 8 millisekund müddətində isə Apache və Nginx-in 98%-i bütün tələbləri yerinə yetirmişdir.
5000 tələbin işlənmə müddəti:
5000 tələbin işlənmə müddəti:
Əgər sizin 3.5GHz CPU və 8 nüvəli virtual maşınınız varsa, istədiyinizi seçin. Bu testdə bütün veb serverlər çox oxşardır. Hər host üçün hansı veb serveri seçmək haqqında aşağıda danışacağıq.
Biraz daha real vəziyyətlərdə bütün veb serverlər bir-birinə yaxındır.
Keçiricilik:
Eyni anda olan bağlantılar sayından gecikmə qrafiki. Daha düz və aşağı – daha yaxşıdır. Son 2% qrafikdən çıxarıldı, çünki onları oxunmaz edəcəkdi.
İndi virtual hostinqdə yerləşən server variantını nəzərdən keçirək. 4 ədəd 2.2GHz və bir ədəd 1.8GHz nüvəni götürək.
Necə şaxələnir
Əgər siz elektrik vakuum triodların, pentodların və s.-nin VAX-larını gördünüzsə, bu qrafiklər sizə tanış olacaq. Biz məhz bunu tutmağa çalışırıq – doymuşluğu. Nüvələrin sayı nə qədər olsa da, performansın artmasında fərq görünməyəcək nöqtə.
Əvvəllər bütün çağırış, mümkün qədər düz bir xətt saxlayaraq 98% sorğuları ən aşağı gecikmə ilə emal etmək idi. İndi isə digər bir xəttin qurulması ilə hər bir server üçün optimal iş nöqtəsini tapacağıq.
Bunun üçün Requests per second (RPR) göstəricisini götürək. Üfiqi oxda tezlik, şaquli oxda – bir saniyədə emal edilən sorğuların sayı, xətlər – nüvələrin sayı.
Nginx-in bir-birinə ardıcıl olaraq sorğuları necə emal etdiyinin korrelyasiyası göstərilir. Belə testlərdə 8 nüvə daha yaxşı nəticələr göstərir.
Bu qrafikdə görünür ki, Nginx bir nüvədə (çox da deyil) daha yaxşı işləyir. Əgər sizdə Nginx varsa, yalnız statik resursları yerləşdirirsinizsə, nüvələrin sayını birə endirmək haqqında düşünmək yaxşıdır.
IIS, Chrome-da DevTools-a görə ən aşağı TTFB-yə malik olsa da, Apache Foundation tərəfindən keçirilən ciddi stress testlərində Nginx və Apache-yə qalib gələ bilmir.
Qrafiklərin hər birinin xarakterik əyriliyi dəqiq təqdim olunub.
Bir növ nəticə:
Bəli, Apache 1 və 8 nüvədə aydın şəkildə daha pis işləyir, 4-də isə bir az yaxşıdır.
Bəli, Nginx 8 nüvədə bir-bir ardıcıllıqla daha yaxşı sorğuları emal edir, 1 və 4 nüvədə isə çoxluğu olan bağlantılarda daha pis işləyir.
Bəli, IIS çoxtəsirli yük üçün 4 nüvəni, tək təsirli yük üçün isə 8 nüvəni üstün tutur. Nəticədə, IIS yüksək yük altında 8 nüvədə bütün serverlərdən bir az daha sürətli çıxdı, amma bütün serverlər bərabər yarışdı.
Bu ölçmə səhvi deyil, burada gecikmələrdə səhv ±1ms-dən, RPR üçün isə ±2-3 sorğuya qədərdir.
8 nüvənin daha pis olduğu nəticələri heç də gözlənilməz deyil; bir çox nüvə və SMT/Hyperthreading, bütün pipeline-i tamamlamağa çalışdığımız zaman performansı ciddi şəkildə azaldır.
Mənbə: habr.com
