Методология жөнүндө сөз кылдык Бул макалада биз HTTPSти сынап жатабыз, бирок реалдуураак сценарийлерде. Сыноо үчүн биз Let's Encrypt сертификатын алдык жана Brotli кысуусун 11ге чейин иштеттик.
Бул жолу биз серверди VDSке же виртуалдык машина катары стандарттуу процессору бар хостто жайгаштыруу сценарийин кайра чыгарууга аракет кылабыз. Бул максатта төмөнкүдөй чек коюлган:
- 25% - Бул ~ 1350 МГц жыштыгына барабар
- 35% -1890MHz
- 41% - 2214 МГц
- 65% - 3510 МГц
Бир жолку байланыштардын саны 500дөн 1, 3, 5, 7 жана 9га чейин кыскарды,
жыйынтыгы:
Кечигүүлөр:
TTFB атайын өзүнчө тест катары киргизилген, анткени HTTPD куралдары ар бир жеке суроо үчүн жаңы колдонуучуну түзөт. Бул тест дагы эле реалдуулуктан ажырап турат, анткени колдонуучу дагы эле бир нече баракты чыкылдатып, ал эми иш жүзүндө TTFP негизги ролду ойнойт.
Биринчи, негизинен IIS виртуалдык машинасын биринчи жолу ишке киргизгенден кийинки эң биринчи суроо орточо 120 мс талап кылат.
Бардык кийинки суроо-талаптар 1.5 мс TTFP көрсөтөт. Apache жана Nginx бул жагынан артта калууда. Жеке автор бул сынакты эң ачык деп эсептейт жана анын негизинде гана жеңүүчүнү тандайт.
Натыйжа таң калыштуу эмес, анткени IIS буга чейин кысылган статикалык мазмунду кэштейт жана ага кирген сайын аны кысып койбойт.
Бир кардарга сарпталган убакыт
Майнаптуулукту баалоо үчүн 1 жалгыз туташуу менен сыноо жетиштүү.
Мисалы, IIS 5000 секунданын ичинде 40 колдонуучунун сыноосун аяктады, бул секундасына 123 суроону түзөт.
Төмөнкү графиктер сайттын мазмуну толугу менен которулганга чейин убакытты көрсөтөт. Бул белгилүү бир убакытта аткарылган сурамдардын үлүшү. Биздин учурда, бардык сурамдардын 80% IISде 8 мс жана Apache жана Nginxте 4.5 мс иштетилди, ал эми Apache жана Nginx боюнча бардык сурамдардын 8% 98 миллисекундга чейинки аралыкта аткарылды.
5000 сурам иштелип чыккан убакыт:
5000 сурам иштелип чыккан убакыт:
Эгер сизде 3.5 ГГц 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 ашпайт. кечиктирүүлөрдө жана RPR үчүн секундасына +- 2-3 суроодон ашык эмес.
8 өзөктүн начар иштеген натыйжалары таң калыштуу эмес, көптөгөн өзөктөр жана SMT/Hyperthreading иштөөнү бир топ начарлатат, эгерде бизде бүт түтүктү бүтүрүшүбүз керек болгон убакыт алкагы болсо.
Source: www.habr.com