Mēs runājām par metodiku rakstu, šajā mēs pārbaudām HTTPS, bet reālākos scenārijos. Pārbaudei mēs ieguvām sertifikātu Let's Encrypt un iespējojām Brotli saspiešanu līdz 11.
Šoreiz mēģināsim reproducēt scenāriju, kad serveris tiek izvietots VDS vai kā virtuālā mašīna resursdatorā ar standarta procesoru. Šim nolūkam tika noteikts ierobežojums:
- 25% - kas atbilst frekvencei ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Vienreizējo savienojumu skaits ir samazināts no 500 līdz 1, 3, 5, 7 un 9,
Rezultāti:
Kavēšanās:
TTFB tika īpaši iekļauts kā atsevišķs tests, jo HTTPD rīki katram atsevišķam pieprasījumam izveido jaunu lietotāju. Šis tests joprojām ir diezgan atrauts no realitātes, jo lietotājs vienalga noklikšķinās uz pāris lapām, un patiesībā TTFP būs galvenā loma.
Pirmais, parasti pats pirmais pieprasījums pēc IIS virtuālās mašīnas pirmās palaišanas aizņem vidēji 120 ms.
Visi turpmākie pieprasījumi parāda 1.5 ms TTFP. Apache un Nginx šajā ziņā atpaliek. Personīgi autors uzskata, ka šis tests ir visvairāk atklājošais, un uzvarētāju izvēlētos tikai pēc tā.
Rezultāts nav pārsteidzošs, jo IIS kešatmiņā saglabā jau saspiestu statisko saturu un nesaspiež to katru reizi, kad tam piekļūst.
Vienam klientam patērētais laiks
Lai novērtētu veiktspēju, pietiek ar pārbaudi ar vienu savienojumu.
Piemēram, IIS pabeidza 5000 lietotāju pārbaudi 40 sekundēs, kas ir 123 pieprasījumi sekundē.
Zemāk esošie grafiki parāda laiku, līdz vietnes saturs ir pilnībā pārsūtīts. Šī ir noteiktā laikā izpildīto pieprasījumu proporcija. Mūsu gadījumā 80% no visiem pieprasījumiem tika apstrādāti 8 ms IIS un 4.5 ms, izmantojot Apache un Nginx, un 8% no visiem pieprasījumiem Apache un Nginx tika izpildīti intervālā līdz 98 milisekundēm.
Laiks, kurā tika apstrādāti 5000 pieprasījumu:
Laiks, kurā tika apstrādāti 5000 pieprasījumu:
Ja jums ir virtuālā mašīna ar 3.5 GHz centrālo procesoru un 8 kodoliem, izvēlieties, ko vēlaties. Visi tīmekļa serveri šajā pārbaudē ir ļoti līdzīgi. Tālāk mēs runāsim par to, kuru tīmekļa serveri izvēlēties katram resursdatoram.
Runājot par nedaudz reālāku situāciju, visi tīmekļa serveri iet viens pret otru.
caurlaide:
Aizkaves grafiks pret vienlaicīgu savienojumu skaitu. Gludāks un zemāks ir labāks. Pēdējie 2% tika noņemti no diagrammām, jo tie padarītu tos nelasāmus.
Tagad apsvērsim iespēju, kur serveris tiek mitināts virtuālajā mitināšanā. Ņemsim 4 kodolus pie 2.2 GHz un vienu kodolu ar frekvenci 1.8 GHz.
Kā mērogot
Ja kādreiz esat redzējis, kā izskatās vakuuma triožu, pentožu un tā tālāk strāvas-sprieguma raksturlielumi, šie grafiki jums būs pazīstami. Tas ir tas, ko mēs cenšamies noķert – piesātinājumu. Ierobežojums ir tad, kad neatkarīgi no tā, cik daudz kodolu jūs izmetat, veiktspējas pieaugums nebūs manāms.
Iepriekš viss izaicinājums bija apstrādāt 98% pieprasījumu ar viszemāko latentumu visiem pieprasījumiem, saglabājot līkni pēc iespējas plakanāku. Tagad, izveidojot citu līkni, mēs atradīsim optimālo darbības punktu katram no serveriem.
Lai to izdarītu, ņemsim indikatoru Pieprasījumi sekundē (RPR). Horizontāli ir frekvence, vertikāle ir apstrādāto pieprasījumu skaits sekundē, līnijas ir kodolu skaits.
Parāda korelāciju tam, cik labi Nginx apstrādā pieprasījumus vienu pēc otra. 8 kodoli šajā testā darbojas labāk.
Šis grafiks skaidri parāda, cik daudz labāk (ne daudz) Nginx darbojas vienā kodolā. Ja jums ir Nginx, apsveriet iespēju samazināt kodolu skaitu līdz vienam, ja mitināt tikai statiskus.
IIS, lai gan saskaņā ar DevTools pārlūkā Chrome tai ir viszemākais TTFB, nopietnā cīņā ar Apache fonda stresa testu spēj zaudēt gan Nginx, gan Apache.
Visi grafiku izliekumi ir atveidoti dzelzs pārklājumā.
Kaut kāds secinājums:
Jā, Apache sliktāk darbojas uz 1 un 8 kodoliem, bet darbojas nedaudz labāk uz 4.
Jā, Nginx uz 8 kodoliem labāk apstrādā pieprasījumus vienu pēc otra, 1 un 4 kodolos, un darbojas sliktāk, ja ir daudz savienojumu.
Jā, IIS dod priekšroku 4 kodoliem daudzpavedienu darba slodzēm un 8 kodoliem viena pavediena darba slodzēm. Galu galā IIS bija nedaudz ātrāks par visiem pārējiem 8 kodolos ar lielu slodzi, lai gan visi serveri bija vienādi.
Tā nav mērījumu kļūda, kļūda šeit nav lielāka par +-1ms. kavēšanās un ne vairāk kā +- 2-3 pieprasījumi sekundē RPR.
Rezultāti, kuros 8 kodoli darbojas sliktāk, nemaz nav pārsteidzoši, daudzi kodoli un SMT/Hyperthreading ievērojami pasliktina veiktspēju, ja mums ir laika posms, kurā mums ir jāpabeidz viss konveijera process.
Avots: www.habr.com