Бид аргачлалын талаар ярилцсан Энэ нийтлэлд бид HTTPS-ийг туршиж үздэг, гэхдээ илүү бодит хувилбараар. Туршилтын хувьд бид Let's Encrypt сертификат авч, Brotli шахалтыг 11 болгож идэвхжүүлсэн.
Энэ удаад бид серверийг VDS дээр эсвэл стандарт процессортой хост дээр виртуал машин болгон байрлуулах хувилбарыг дахин гаргахыг хичээх болно. Энэ зорилгоор дараахь хязгаарлалтыг тогтоосон.
- 25% - Энэ нь ~ 1350 МГц давтамжтай тэнцэнэ
- 35% -1890 МГц
- 41% - 2214 МГц
- 65% - 3510 МГц
Нэг удаагийн холболтын тоог 500-аас 1, 3, 5, 7, 9 болгон бууруулж,
Үр дүн:
Саатал:
HTTPD хэрэгсэл нь хүсэлт бүрт шинэ хэрэглэгчийг бий болгодог тул TTFB-г тусгайлан тусдаа тест болгон оруулсан болно. Энэ тест нь бодит байдлаас нэлээд салсан хэвээр байгаа, учир нь хэрэглэгч хэд хэдэн хуудсыг дарах бөгөөд бодит байдал дээр TTFP гол үүрэг гүйцэтгэх болно.
Эхний, ерөнхийдөө IIS виртуал машиныг эхлүүлсний дараа хамгийн анхны хүсэлт нь дунджаар 120 мс болдог.
Дараагийн бүх хүсэлтүүд нь 1.5 мс-ийн TTFP-г харуулж байна. Apache болон Nginx энэ тал дээр хоцорч байна. Зохиогч хувьдаа энэ тестийг хамгийн ил тод гэж үздэг бөгөөд зөвхөн түүн дээр үндэслэн ялагчийг сонгох болно.
IIS нь аль хэдийн шахсан статик агуулгыг кэш болгож, хандалт хийх болгондоо шахдаггүй тул үр дүн нь гайхмаар зүйл биш юм.
Нэг үйлчлүүлэгчид зарцуулсан цаг
Гүйцэтгэлийг үнэлэхийн тулд 1 холболттой тест хийхэд хангалттай.
Жишээлбэл, IIS нь 5000 хэрэглэгчийн тестийг 40 секундын дотор хийсэн бөгөөд энэ нь секундэд 123 хүсэлт юм.
Доорх графикууд нь сайтын агуулгыг бүрэн шилжүүлэх хүртэлх хугацааг харуулж байна. Энэ нь тухайн хугацаанд гүйцэтгэсэн хүсэлтийн хувь хэмжээ юм. Манай тохиолдолд бүх хүсэлтийн 80% нь IIS дээр 8ms, Apache болон Nginx дээр 4.5ms, Apache болон Nginx дээрх бүх хүсэлтийн 8% нь 98 миллисекунд хүртэлх хугацаанд хийгдсэн.
5000 хүсэлтийг боловсруулсан хугацаа:
5000 хүсэлтийг боловсруулсан хугацаа:
Хэрэв танд 3.5 GHz CPU, 8 цөмтэй виртуал машин байгаа бол хүссэн зүйлээ сонгоорой. Бүх вэб серверүүд энэ туршилтанд маш төстэй байдаг. Хост бүрт ямар вэб сервер сонгох талаар бид доор ярих болно.
Илүү бодитой нөхцөл байдлын тухай ярихад бүх вэб серверүүд толгойгоо гашилгадаг.
Дамжуулах хэсэг
Нэгэн зэрэг холболтын тоотой харьцуулсан саатлын график. Гөлгөр, бага байх нь дээр. Сүүлийн 2%-ийг унших боломжгүй болгож байгаа тул графикаас хассан.
Одоо серверийг виртуал хостинг дээр байрлуулах сонголтыг авч үзье. 4 ГГц-ийн 2.2 цөм, 1.8 ГГц-ийн нэг цөмийг авч үзье.
Хэрхэн масштаблах вэ
Хэрэв та вакуум триод, пентод гэх мэт гүйдлийн хүчдэлийн шинж чанарууд ямар байдгийг харсан бол эдгээр графикууд танд танил байх болно. Энэ бол бидний барих гэж байгаа зүйл юм - ханасан байдал. Хичнээн цөм шидсэн ч гүйцэтгэлийн өсөлт мэдэгдэхүйц биш байх үед хязгаарлалт байдаг.
Өмнө нь бүх хүсэлтийн 98%-ийг бүх хүсэлтийн хамгийн бага хоцрогдолтойгоор боловсруулж, муруйг аль болох тэгш байлгах явдал байв. Одоо өөр муруй байгуулснаар бид сервер бүрийн оновчтой ажиллах цэгийг олох болно.
Үүнийг хийхийн тулд секундэд хийх хүсэлт (RPR) үзүүлэлтийг авч үзье. Хэвтээ нь давтамж, босоо нь секундэд боловсруулагдсан хүсэлтийн тоо, мөр нь цөмийн тоо юм.
Nginx хүсэлтийг ар араасаа хэр сайн боловсруулдаг хоорондын хамаарлыг харуулдаг. Энэ туршилтанд 8 цөм илүү сайн ажилладаг.
Энэ график нь Nginx нэг цөм дээр хэр сайн (их биш) ажиллаж байгааг тодорхой харуулж байна. Хэрэв танд Nginx байгаа бол, хэрэв та зөвхөн статикийг байршуулж байгаа бол цөмийн тоог нэг болгон багасгах талаар бодох хэрэгтэй.
IIS нь Chrome дахь DevTools-ийн дагуу хамгийн бага TTFB-тэй хэдий ч Apache сангийн стресс тесттэй ноцтой тэмцэлд Nginx болон Apache-д хожигдож чадсан.
Графикуудын бүх муруйлтыг төмрөөр бүрсэн байна.
Зарим төрлийн дүгнэлт:
Тиймээ, Apache нь 1 ба 8 цөм дээр муу ажилладаг боловч 4 дээр арай дээр ажилладаг.
Тиймээ, 8 цөм дээрх Nginx нь хүсэлтийг 1 ба 4 цөм дээр ар араасаа илүү сайн боловсруулж, олон холболттой үед илүү муу ажилладаг.
Тийм ээ, IIS нь олон урсгалтай ажлын ачаалалд 4 цөмийг илүүд үздэг ба нэг урсгалтай ажлын ачаалалд 8 цөмийг илүүд үздэг. Эцсийн эцэст IIS нь өндөр ачаалалтай 8 цөм дээр бусдаас арай хурдан байсан ч бүх серверүүд ижил түвшинд байсан.
Энэ нь хэмжилтийн алдаа биш, энд байгаа алдаа нь +-1ms-ээс ихгүй байна. саатал болон секундэд +- 2-3-аас ихгүй RPR хүсэлт.
8 цөм нь муу ажиллаж байгаа үр дүн нь гайхмаар зүйл биш бөгөөд хэрэв бидэнд дамжуулах хоолойг бүхэлд нь дуусгах цаг хугацаа байгаа бол олон цөм болон SMT/Hyperthreading гүйцэтгэлийг ихээхэн доройтуулдаг.
Эх сурвалж: www.habr.com