Biz metodologiya haqida gaplashdik Ushbu maqolada biz HTTPS-ni sinab ko'ramiz, ammo realroq stsenariylarda. Sinov uchun biz Let's Encrypt sertifikatini oldik va Brotli siqishni 11 ga yoqdik.
Bu safar biz VDS-da serverni yoki standart protsessorli xostda virtual mashina sifatida joylashtirish stsenariysini takrorlashga harakat qilamiz. Buning uchun quyidagi chegara belgilandi:
- 25% - Bu ~ 1350 MGts chastotaga teng
- 35% -1890 MGts
- 41% - 2214 MGts
- 65% - 3510 MGts
Bir martalik ulanishlar soni 500 tadan 1, 3, 5, 7 va 9 tagacha qisqartirildi.
Natijalar:
Kechikishlar:
TTFB alohida test sifatida kiritilgan, chunki HTTPD Tools har bir alohida so'rov uchun yangi foydalanuvchi yaratadi. Ushbu test hali ham haqiqatdan ajralgan, chunki foydalanuvchi hali ham bir nechta sahifani bosadi va aslida TTFP asosiy rolni o'ynaydi.
Birinchi, odatda, IIS virtual mashinasi birinchi ishga tushirilgandan keyin birinchi so'rov o'rtacha 120 milodiy vaqtni oladi.
Barcha keyingi so'rovlar 1.5 milodiy TTFPni ko'rsatadi. Apache va Nginx bu borada ortda qolmoqda. Shaxsan muallif ushbu testni eng ochiq deb hisoblaydi va g'olibni faqat shu asosda tanlaydi.
Natija ajablanarli emas, chunki IIS allaqachon siqilgan statik tarkibni keshlaydi va har safar kirishda uni siqmaydi.
Har bir mijoz uchun sarflangan vaqt
Ishlashni baholash uchun 1 ta bitta ulanish bilan sinov kifoya qiladi.
Misol uchun, IIS 5000 soniyada 40 foydalanuvchini sinovdan o'tkazdi, bu soniyada 123 ta so'rov.
Quyidagi grafiklar sayt tarkibi to'liq o'tkazilgunga qadar vaqtni ko'rsatadi. Bu ma'lum vaqt ichida bajarilgan so'rovlarning nisbati. Bizning holatda, barcha so'rovlarning 80% IIS da 8 ms va Apache va Nginx da 4.5 ms da qayta ishlandi va Apache va Nginx dagi barcha so'rovlarning 8 foizi 98 millisekundgacha bo'lgan vaqt oralig'ida bajarildi.
5000 ta soʻrov koʻrib chiqilgan vaqt:
5000 ta soʻrov koʻrib chiqilgan vaqt:
Agar sizda 3.5 gigagertsli protsessor va 8 yadroli virtual mashinangiz bo'lsa, o'zingiz xohlagan narsani tanlang. Ushbu testda barcha veb-serverlar juda o'xshash. Quyida har bir xost uchun qaysi veb-serverni tanlash haqida gaplashamiz.
Biroz realroq vaziyat haqida gap ketganda, barcha veb-serverlar bir-biriga o'tadi.
O'tkazish vaqti:
Bir vaqtning o'zida ulanishlar soniga nisbatan kechikishlar grafigi. Silliq va pastroq bo'lsa yaxshi. Oxirgi 2% jadvallardan olib tashlandi, chunki ular ularni o'qib bo'lmaydi.
Endi server virtual hostingda joylashgan variantni ko'rib chiqamiz. Keling, 4 gigagertsli 2.2 yadroni va 1.8 gigagertsli bir yadroni olaylik.
Qanday masshtablash kerak
Agar siz vakuum triodlari, pentodalar va boshqalarning oqim kuchlanish xususiyatlari qanday ko'rinishini ko'rgan bo'lsangiz, bu grafiklar sizga tanish bo'ladi. Bu biz qo'lga olishga harakat qilmoqdamiz - to'yinganlik. Cheklov shundan iboratki, siz qancha yadro tashlasangiz ham, unumdorlikning oshishi sezilmaydi.
Ilgari, butun muammo so'rovlarning 98 foizini barcha so'rovlar uchun eng past kechikish bilan qayta ishlash va egri chiziqni iloji boricha tekis saqlash edi. Endi, boshqa egri chiziqni qurish orqali biz har bir server uchun optimal ish nuqtasini topamiz.
Buning uchun soniyada so'rovlar (RPR) ko'rsatkichini olaylik. Gorizontal - chastota, vertikal - soniyada qayta ishlangan so'rovlar soni, chiziqlar - yadrolar soni.
Nginx so'rovlarni birin-ketin qayta ishlash darajasining korrelyatsiyasini ko'rsatadi. Ushbu testda 8 yadro yaxshiroq ishlaydi.
Ushbu grafik Nginx bir yadroda qanchalik yaxshi (ko'p emas) ishlashini aniq ko'rsatadi. Agar sizda Nginx bo'lsa, faqat statik yadrolarga ega bo'lsangiz, yadrolar sonini bittaga kamaytirish haqida o'ylashingiz kerak.
IIS, Chrome'dagi DevTools-ga ko'ra eng past TTFBga ega bo'lsa-da, Apache Foundation tomonidan o'tkazilgan stress testi bilan jiddiy kurashda Nginx va Apache-ga yutqazishga muvaffaq bo'ldi.
Grafiklarning barcha egri chiziqlari temir bilan qoplangan.
Qandaydir xulosa:
Ha, Apache 1 va 8 yadrolarida yomonroq ishlaydi, lekin 4 yadrosida biroz yaxshiroq ishlaydi.
Ha, 8 yadroli Nginx so'rovlarni birin-ketin, 1 va 4 yadrolarda yaxshiroq qayta ishlaydi va ko'p ulanishlar mavjud bo'lganda yomonroq ishlaydi.
Ha, IIS ko'p tarmoqli ish yuklari uchun 4 yadroni afzal ko'radi va bitta tarmoqli ish yuklari uchun 8 yadroni afzal ko'radi. Oxir oqibat, barcha serverlar teng bo'lsa-da, yuqori yuk ostida 8 yadroda IIS boshqalarga qaraganda bir oz tezroq edi.
Bu o'lchov xatosi emas, bu erda xatolik +-1ms dan oshmaydi. kechikishlarda va RPR uchun soniyada +- 2-3 so'rovdan ko'p bo'lmagan.
8 yadroning yomon ishlashi ajablanarli emas, ko'p yadrolar va SMT/Hyperthreading ish faoliyatini sezilarli darajada pasaytiradi, agar biz butun quvur liniyasini yakunlashimiz kerak bo'lgan vaqt oralig'iga ega bo'lsak.
Manba: www.habr.com