A módszerről korábban írtunk cikkünkben, itt pedig az HTTPS tesztelését végezzük valósághűbb forgatókönyvekben. A teszteléshez Let's Encrypt tanúsítványt szereztünk be, a Brotli tömörítést pedig 11-re állítottuk.
Ezúttal megpróbáljuk újraalkotni a VDS-re telepített szerver vagy virtuális gép forgatókönyvét egy tipikus processzorral rendelkező hoston. Ehhez a következő korlátokat állítottuk be:
- 25% — Ez körülbelül 1350 MHz-re fordítva
- 35% - 1890 MHz
- 41% — 2214 MHz
- 65% — 3510 MHz
A párhuzamos kapcsolatok száma 500-ról 1, 3, 5, 7 és 9-re csökkent.
Results:
Késések:
A TTFB-t kifejezetten külön tesztként emeltük ki, mert az HTTPD Tools minden egyes kéréshez szinte új felhasználót hoz létre. Ez a teszt még mindig elég elszakadt a valóságtól, mivel a felhasználók valószínűleg néhány oldalt kattintanak, és valójában a TTFP játszik itt központi szerepet.
Az első, általában legelső kérés a virtuális gép IIS első indítása után átlagosan 120 ms alatt teljesül.
Minden további kérés 1,5 ms TTFP-t mutat. Az Apache és Nginx e téren lemarad. Személyesen az író ezt a tesztet tartja a legmegbízhatóbbnak, és csak ennek alapján választana győztest.
Az eredmény nem meglepő, mivel az IIS már tömörített statikus tartalmat gyorsítótáraz, nem újra tömöríti minden alkalommal, amikor hozzáférnek.
Az egy ügyfélre fordított idő
A teljesítmény értékeléséhez elegendő egy 1 párhuzamos kapcsolattal végzett teszt.
Például az IIS a 5000 felhasználóra vonatkozó tesztet 40 másodperc alatt fejezte be, ami 123 kérés másodpercenként.
Az alábbi grafikonok a weboldal teljes tartalomátadási idejét mutatják. Ez az időtartam, amennyi alatt a kérdéseket teljesítették. A mi esetünkben a kérdések 80%-a 8 ms-on belül került feldolgozásra az IIS-en, míg az Apache-on és Nginx-en 4,5 ms alatt, az 8 ms-on belüli időintervallumon belül pedig a kérdések 98%-át teljesítették az Apache-on és Nginx-en.
Az az idő, amíg 5000 kérdést feldolgoztak:
Az az idő, amíg 5000 kérdést feldolgoztak:
Ha van egy virtuális gépe 3,5 GHz-es CPU-val és 8 maggal, válassza azt, amit szeretne. A webkiszolgálók nagyon hasonlóak ebben a tesztelésben. Arról, hogy melyik webkiszolgálót válasszuk minden hosthoz, lentebb beszélünk.
Ha egy kicsit valósabb helyzetről van szó, minden webkiszolgáló fej-fej mellett halad.
Átviteli sebesség:
A késések grafikonja az egyidejű kapcsolatok számától függően. Ha simább és alacsonyabb – az jobb. Az utolsó 2%-ot eltávolítottuk a diagramokból, mert olvashatatlanná tenné őket.
Most nézzük meg azt a lehetőséget, ahol a szerver virtuális tárhelyen van elhelyezve. Vegyünk 4 magot 2,2 GHz-el és egy magot 1,8 GHz-el.
Hogyan skálázódnak
Ha valaha is láttad, hogyan néznek ki az elektroncsövek, pentódok és így tovább, ezek a grafikonok ismerősek lesznek számodra. Ezt próbáljuk megragadni – telítettség. Az a határ, amikor bármennyi magot is használunk, a teljesítménynövekedés már nem lesz észrevehető.
Korábban a kihívás abban állt, hogy a lehető legkisebb késleltetéssel kezeljük a kérések 98%-át, és a görbét a lehető legsimábbá tartsuk. Most egy másik görbe segítségével megtaláljuk az optimális munkapontot minden szerver esetében.
Ehhez vegyük figyelembe a másodpercenkénti kérések számát (RPR). A vízszintes tengelyen a frekvencia, a függőleges tengelyen pedig a másodpercenként feldolgozott kérések száma, a vonalak pedig a magok számát jelölik.
Itt látható a korreláció, mennyire jól kezeli az Nginx a kéréseket egymás után. 8 mag ebben a tesztelésben jobban teljesít.
Ezen a grafikonon jól látszik, mennyivel jobban (nem sokkal) működik az Nginx egy magon. Ha az Nginx-et használod, érdemes elgondolkodnod a magok számának egyre csökkentésén, ha csak statikus tartalmat hosztálsz.
Az IIS, bár a Chrome DevTools szerint a legalacsonyabb TTFB-vel rendelkezik, képes elveszíteni az Nginx és az Apache előtt egy komoly stresszteszten az Apache Foundation-től.
A grafikonok görbülete vasban reprodukálható.
Valamilyen következtetés:
Igen, az Apache vasban rosszabbul teljesít 1 és 8 magon, de 4 magon kissé jobban működik.
Igen, az Nginx 8 magon jobban kezeli a kéréseket egymás után, 1 és 4 magon pedig rosszabbul teljesít, amikor sok kapcsolatra van szükség.
Igen, az IIS a 4 magot kedveli a több szálas terhelésnél, és a 8 magot kedveli az egy szálas terhelésnél. Végső soron az IIS kicsit gyorsabb volt mindegyiknél 8 magon magas terhelés alatt, bár minden szerver egyenlő szinten mozgott.
Ez nem mérési hiba, a hibahatár itt nem több, mint ±1 ms a késleltetésekben, és nem több, mint ±2-3 kérés másodpercenként az RPR esetében.
A 8 magos eredmények, amikor rosszabbul teljesítenek, egyáltalán nem meglepőek; sok mag és SMT/Hyperthreading jelentősen rontja a teljesítményt, ha van egy időkeret, amelyen belül a teljes pipelinet be kell fejezni.
Forrás: habr.com
