Metodologiya haqqında danışdıq Bu məqalədə HTTPS-i sınaqdan keçiririk, lakin daha real ssenarilərdə. Test üçün biz Let's Encrypt sertifikatı əldə etdik və Brotli sıxılmasını 11-ə qədər aktiv etdik.
Bu dəfə biz serverin VDS-də və ya standart prosessoru olan hostda virtual maşın kimi yerləşdirilməsi ssenarisini təkrar etməyə çalışacağıq. Bu məqsədlə limit müəyyən edilmişdir:
- 25% - Bu ~ 1350 MHz tezliyinə bərabərdir
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Birdəfəlik qoşulmaların sayı 500-dən 1, 3, 5, 7 və 9-a endirildi,
Nəticələr:
Gecikmələr:
TTFB xüsusi olaraq ayrıca test kimi daxil edilmişdir, çünki HTTPD Alətləri hər bir fərdi sorğu üçün yeni istifadəçi yaradır. Bu test hələ də reallıqdan tamamilə uzaqdır, çünki istifadəçi hələ də bir neçə səhifəni klikləyəcək və əslində TTFP əsas rolu oynayacaq.
Birinci, ümumiyyətlə, IIS virtual maşınının ilk işə salınmasından sonra ilk sorğu orta hesabla 120 ms çəkir.
Bütün sonrakı sorğular 1.5 ms TTFP göstərir. Apache və Nginx bu baxımdan geri qalır. Şəxsən müəllif bu testi ən aşkar test hesab edir və qalibi yalnız ona əsaslanaraq seçəcək.
Nəticə təəccüblü deyil, çünki IIS artıq sıxılmış statik məzmunu önbelleğe alır və hər dəfə daxil olduqda onu sıxmır.
Hər müştəriyə sərf olunan vaxt
Performansı qiymətləndirmək üçün 1 tək əlaqə ilə sınaq kifayətdir.
Məsələn, IIS 5000 istifadəçinin sınağını 40 saniyə ərzində tamamladı ki, bu da saniyədə 123 sorğu deməkdir.
Aşağıdakı qrafiklər sayt məzmununun tamamilə köçürülməsinə qədər olan vaxtı göstərir. Bu, müəyyən vaxt ərzində tamamlanan sorğuların nisbətidir. Bizim vəziyyətimizdə bütün sorğuların 80%-i IIS-də 8 ms-də və Apache və Nginx-də 4.5 ms-də işlənmişdir və Apache və Nginx-də bütün sorğuların 8%-i 98 millisaniyəyə qədər intervalda tamamlanmışdır.
5000 sorğunun işləndiyi vaxt:
5000 sorğunun işləndiyi vaxt:
Əgər 3.5 GHz 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. Aşağıda hər bir host üçün hansı veb serveri seçmək barədə danışacağıq.
Bir az daha real vəziyyətə gəldikdə, bütün veb serverlər baş-başa gedirlər.
Həcmi:
Eyni vaxtda qoşulmaların sayına qarşı gecikmələrin qrafiki. Hamar və aşağı daha yaxşıdır. Son 2% qrafiklərdən silindi, çünki onları oxunmaz edəcəklər.
İndi serverin virtual hostinqdə yerləşdiyi variantı nəzərdən keçirək. 4 GHz-də 2.2 nüvəni və 1.8 GHz-də bir nüvəni götürək.
Necə ölçmək olar
Əgər siz vakuum triodlarının, pentodların və s. cərəyan gərginlik xüsusiyyətlərinin necə olduğunu görmüsünüzsə, bu qrafiklər sizə tanış olacaq. Tutmağa çalışdığımız budur - doyma. Məhdudiyyət odur ki, nə qədər nüvə atsanız da, performans artımı nəzərə çarpmayacaq.
Əvvəllər bütün problem əyrini mümkün qədər düz saxlamaqla bütün sorğular üçün ən aşağı gecikmə ilə sorğuların 98%-ni emal etmək idi. İndi başqa bir əyri quraraq, serverlərin hər biri üçün optimal əməliyyat nöqtəsini tapacağıq.
Bunu etmək üçün saniyədə sorğular (RPR) göstəricisini götürək. Horizontal tezlik, şaquli saniyədə emal edilən sorğuların sayı, xətlər nüvələrin sayıdır.
Nginx sorğuları bir-birinin ardınca nə qədər yaxşı emal etdiyinin korrelyasiyasını göstərir. 8 nüvə bu testdə daha yaxşı çıxış edir.
Bu qrafik Nginx-in bir nüvədə nə qədər yaxşı (çox deyil) işlədiyini açıq şəkildə göstərir. Əgər sizdə Nginx varsa, yalnız statik olanları yerləşdirirsinizsə, nüvələrin sayını birinə endirməyi düşünməlisiniz.
IIS, Chrome-da DevTools-a görə ən aşağı TTFB-yə sahib olsa da, Apache Fondunun stress testi ilə ciddi mübarizədə həm Nginx, həm də Apache-yə uduzmağı bacarır.
Qrafiklərin bütün əyrilikləri dəmirlə örtülmüş şəkildə təkrarlanır.
Bir növ nəticə:
Bəli, Apache 1 və 8 nüvələrdə daha pis işləyir, lakin 4-də bir az daha yaxşı işləyir.
Bəli, 8 nüvəli Nginx sorğuları bir-birinin ardınca, 1 və 4 nüvələrdə daha yaxşı emal edir və çoxlu bağlantılar olduqda daha pis işləyir.
Bəli, IIS çox yivli iş yükləri üçün 4 nüvəyə, tək yivli iş yükləri üçün isə 8 nüvəyə üstünlük verir. Nəhayət, IIS yüksək yük altında 8 nüvədə hamıdan bir qədər sürətli idi, baxmayaraq ki, bütün serverlər bərabər idi.
Bu ölçmə xətası deyil, burada səhv +-1ms-dən çox deyil. gecikmələrdə və RPR üçün saniyədə +- 2-3 sorğudan çox olmamaqla.
8 nüvənin daha pis performans göstərdiyi nəticələr heç də təəccüblü deyil, bir çox nüvələr və SMT/Hyperthreading, bütün boru kəmərini tamamlamalı olduğumuz bir vaxt çərçivəmiz varsa, performansı çox pisləşdirir.
Mənbə: www.habr.com