Մենք խոսեցինք մեթոդաբանության մասին հոդվածում, այս մեկում մենք փորձարկում ենք HTTPS, բայց ավելի իրատեսական սցենարներով: Փորձարկման համար մենք ստացանք Let's Encrypt վկայագիր և միացրինք Brotli-ի սեղմումը 11-ին:
Այս անգամ մենք կփորձենք վերարտադրել սերվերի տեղադրման սցենարը VDS-ի վրա կամ որպես վիրտուալ մեքենա՝ ստանդարտ պրոցեսորով հոսթի վրա: Այդ նպատակով սահմանվել է.
- 25% - Որը համարժեք է ~ 1350 ՄՀց հաճախականությանը
- 35% -1890 ՄՀց
- 41% - 2214 ՄՀց
- 65% - 3510 ՄՀց
Միանվագ միացումների թիվը 500-ից կրճատվել է մինչև 1, 3, 5, 7 և 9,
Արդյունքները:
Ուշացումներ:
TTFB-ն հատուկ ներառված էր որպես առանձին թեստ, քանի որ HTTPD Tools-ը ստեղծում է նոր օգտվող յուրաքանչյուր անհատական հարցման համար: Այս թեստը դեռ բավականին կտրված է իրականությունից, քանի որ օգտվողը դեռ սեղմելու է մի քանի էջ, իսկ իրականում TTFP-ն կխաղա գլխավոր դերը։
Առաջին, ընդհանուր առմամբ, առաջին հարցումը IIS վիրտուալ մեքենայի առաջին մեկնարկից հետո տևում է միջինը 120 ms:
Բոլոր հետագա հարցումները ցույց են տալիս TTFP 1.5 ms: Apache-ն ու Nginx-ն այս հարցում ետ են մնում։ Անձամբ հեղինակն այս թեստը համարում է ամենաբացահայտիչը և միայն դրա հիման վրա կընտրեր հաղթողին։
Արդյունքը զարմանալի չէ, քանի որ IIS-ը պահում է արդեն սեղմված ստատիկ բովանդակությունը և չի սեղմում այն ամեն անգամ, երբ այն մուտք է գործում:
Մեկ հաճախորդի համար ծախսված ժամանակը
Արդյունավետությունը գնահատելու համար բավարար է 1 միացումով թեստը:
Օրինակ, IIS-ն ավարտեց 5000 օգտատերերի թեստը 40 վայրկյանում, ինչը կազմում է վայրկյանում 123 հարցում:
Ստորև բերված գրաֆիկները ցույց են տալիս ժամանակը, մինչև կայքի բովանդակությունը ամբողջությամբ փոխանցվի: Սա տվյալ ժամանակահատվածում կատարված հարցումների համամասնությունն է: Մեր դեպքում բոլոր հարցումների 80%-ը մշակվել է IIS-ում 8ms-ով և Apache-ում և Nginx-ում 4.5ms-ով, իսկ Apache-ի և Nginx-ի բոլոր հարցումների 8%-ը կատարվել է մինչև 98 միլիվայրկյան ընդմիջումով:
Ժամանակը, որի ընթացքում մշակվել է 5000 հարցում.
Ժամանակը, որի ընթացքում մշակվել է 5000 հարցում.
Եթե ունեք վիրտուալ մեքենա 3.5 ԳՀց պրոցեսորով և 8 միջուկով, ապա ընտրեք այն, ինչ ցանկանում եք: Բոլոր վեբ սերվերները շատ նման են այս թեստավորմանը: Մենք կխոսենք այն մասին, թե որ վեբ սերվերն ընտրել յուրաքանչյուր հոսթի համար ստորև:
Երբ խոսքը վերաբերում է մի փոքր ավելի իրատեսական իրավիճակին, բոլոր վեբ սերվերները գնում են գլուխը:
Արտադրություն.
Ուշացումների գրաֆիկն ընդդեմ միաժամանակյա միացումների քանակի: Ավելի հարթ և ցածր ավելի լավ է: Վերջին 2%-ը հեռացվել է գծապատկերներից, քանի որ դրանք անընթեռնելի կդարձնեն:
Հիմա եկեք դիտարկենք այն տարբերակը, որտեղ սերվերը հոսթինգ է վիրտուալ հոսթինգում: Վերցնենք 4 միջուկ 2.2 ԳՀց հաճախականությամբ և մեկ միջուկ՝ 1.8 ԳՀց:
Ինչպես մասշտաբավորել
Եթե երբևէ տեսել եք, թե ինչպիսին են վակուումային տրիոդների, պենտոդների և այլնի ընթացիկ-լարման բնութագրերը, ապա այս գրաֆիկները ձեզ ծանոթ կլինեն: Սա այն է, ինչ մենք փորձում ենք բռնել՝ հագեցվածություն։ Սահմանն այն է, երբ անկախ նրանից, թե քանի միջուկ եք նետում, կատարողականի աճը նկատելի չի լինի:
Նախկինում ամբողջ խնդիրն էր մշակել հարցումների 98%-ը ամենացածր ուշացումով բոլոր հարցումների համար՝ հնարավորինս հարթ պահելով կորը: Այժմ, կառուցելով մեկ այլ կոր, մենք կգտնենք սերվերներից յուրաքանչյուրի համար գործող օպտիմալ կետը:
Դա անելու համար եկեք վերցնենք «Requests per second» (RPR) ցուցանիշը: Հորիզոնականը հաճախականությունն է, ուղղահայացը մեկ վայրկյանում մշակված հարցումների քանակն է, տողերը՝ միջուկների քանակը:
Ցույց է տալիս հարաբերակցությունը, թե որքան լավ է Nginx-ը մշակում հարցումները մեկը մյուսի հետևից: 8 միջուկներն ավելի լավ են աշխատում այս թեստում:
Այս գրաֆիկը հստակ ցույց է տալիս, թե որքան լավ (ոչ շատ) Nginx-ն աշխատում է մեկ միջուկի վրա: Եթե ունեք Nginx, ապա պետք է հաշվի առնեք միջուկների թիվը մեկին կրճատելու մասին, եթե հյուրընկալում եք միայն ստատիկները:
IIS-ը, չնայած այն ունի ամենացածր TTFB-ն ըստ DevTools-ի Chrome-ում, կարողանում է պարտվել և՛ Nginx-ին, և՛ Apache-ին Apache Foundation-ի սթրես թեստի հետ լուրջ պայքարում:
Գրաֆիկների ամբողջ կորությունը վերարտադրվում է երկաթապատ:
Որոշակի եզրակացություն.
Այո, Apache-ն ավելի վատ է աշխատում 1 և 8 միջուկների վրա, բայց մի փոքր ավելի լավ է աշխատում 4-ի վրա:
Այո, 8 միջուկի վրա Nginx-ը մեկը մյուսի հետևից ավելի լավ է մշակում հարցումները՝ 1 և 4 միջուկների վրա, և ավելի վատ է աշխատում, երբ շատ կապեր կան:
Այո, IIS-ը նախընտրում է 4 միջուկ՝ բազմաշերտ աշխատանքային ծանրաբեռնվածության համար և նախընտրում է 8 միջուկ՝ մեկ թելերով ծանրաբեռնվածության համար: Ի վերջո, IIS-ը մի փոքր ավելի արագ էր, քան բոլորը 8 միջուկների վրա բարձր ծանրաբեռնվածության տակ, չնայած բոլոր սերվերները հավասար էին:
Սա չափման սխալ չէ, այստեղ սխալը +-1ms-ից ոչ ավելի է: ուշացումներով և ոչ ավելի, քան +- 2-3 հարցում մեկ վայրկյանում RPR-ի համար:
Արդյունքները, որտեղ 8 միջուկներն ավելի վատ են աշխատում, ամենևին էլ զարմանալի չեն, շատ միջուկներ և SMT/Hyperthreading-ը մեծապես վատացնում են աշխատանքը, եթե մենք ունենք ժամանակային շրջանակ, որում մենք պետք է ավարտենք ամբողջ խողովակաշարը:
Source: www.habr.com