A módszertanról ben beszélgettünk cikkben, ebben a HTTPS-t teszteljük, de reálisabb forgatókönyvekben. A teszteléshez beszereztük a Let's Encrypt tanúsítványt, és engedélyeztük a Brotli-tömörítést 11-re.
Ezúttal megpróbáljuk reprodukálni azt a forgatókönyvet, amikor egy szervert telepítünk VDS-en vagy virtuális gépként egy szabványos processzorral rendelkező gazdagépen. Ebből a célból a következő határértéket határozták meg:
- 25% – ami ~ 1350 MHz-es frekvenciának felel meg
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Az egyszeri csatlakozások száma 500-ról 1, 3, 5, 7 és 9-re csökkent,
Eredmények:
Késések:
A TTFB kifejezetten külön tesztként szerepelt, mivel a HTTPD Tools minden egyes kéréshez új felhasználót hoz létre. Ez a teszt még eléggé elrugaszkodott a valóságtól, mert a felhasználó így is rákattint pár oldalra, és a valóságban a TTFPé lesz a főszerep.
Az első, általában a legelső kérés az IIS virtuális gép első indítása után átlagosan 120 ms-ot vesz igénybe.
Minden további kérés 1.5 ms-os TTFP-t mutat. Az Apache és a Nginx ebben a tekintetben le vannak maradva. A szerző személy szerint ezt a tesztet tartja a legleleplezőbbnek, és csak ez alapján választaná ki a győztest.
Az eredmény nem meglepő, mivel az IIS gyorsítótárazza a már tömörített statikus tartalmat, és nem tömöríti azt minden alkalommal, amikor hozzáfér.
Ügyfelenként eltöltött idő
A teljesítmény értékeléséhez elegendő egy teszt 1 csatlakozással.
Az IIS például 5000 másodperc alatt hajtott végre egy 40 felhasználó tesztjét, ami 123 kérés másodpercenként.
Az alábbi grafikonok a webhely tartalmának teljes átviteléig eltelt időt mutatják. Ez az adott idő alatt teljesített kérelmek aránya. Esetünkben az összes kérés 80%-a IIS-en 8 ms alatt, Apache és Nginx esetén 4.5 ms alatt, Apache és Nginx rendszeren pedig az összes kérés 8%-a 98 ezredmásodpercig terjedő időközön belül teljesült.
5000 kérelem feldolgozásának időtartama:
5000 kérelem feldolgozásának időtartama:
Ha van virtuális gépe 3.5 GHz-es CPU-val és 8 maggal, válassza ki, mit szeretne. Ebben a tesztelésben minden webszerver nagyon hasonló. Az alábbiakban beszélünk arról, hogy melyik webszervert válasszuk az egyes gazdagépekhez.
Ha egy kicsit reálisabb helyzetről van szó, minden webszerver fej fej mellett halad.
Teljesítmény:
A késések grafikonja az egyidejű kapcsolatok számának függvényében. A simább és alacsonyabb jobb. Az utolsó 2%-ot eltávolítottuk a grafikonokról, mert olvashatatlanná tennék őket.
Most nézzük meg azt a lehetőséget, ahol a kiszolgálót virtuális tárhelyen tárolják. Vegyünk 4 magot 2.2 GHz-en és egy magot 1.8 GHz-en.
Hogyan kell méretezni
Ha valaha is látta, hogyan néznek ki a vákuumtriódák, pentódok és így tovább áram-feszültség jellemzői, ezek a grafikonok ismerősek lesznek. Ezt próbáljuk megfogni – a telítettséget. A határ az, amikor akárhány magot dobsz, a teljesítménynövekedés nem lesz észrevehető.
Korábban a teljes kihívás az volt, hogy a kérelmek 98%-át a legalacsonyabb késleltetéssel dolgozzák fel, a lehető leglaposabb görbével. Most egy újabb görbe felépítésével megtaláljuk az optimális működési pontot minden szerver számára.
Ehhez vegyük a Requests per second (RPR) mutatót. A vízszintes a frekvencia, a függőleges a másodpercenként feldolgozott kérések száma, a sorok a magok száma.
Azt mutatja, hogy az Nginx milyen jól dolgozza fel egymás után a kéréseket. 8 mag jobban teljesít ebben a tesztben.
Ez a grafikon egyértelműen megmutatja, hogy az Nginx mennyivel jobban (nem sokkal) működik egyetlen magon. Ha Nginxet használ, fontolja meg a magok számának egyre csökkentését, ha csak statikusakat tárol.
Noha az IIS a Chrome DevTools szerint a legalacsonyabb TTFB-vel rendelkezik, az Apache Foundation stressztesztjével komoly küzdelemben mind az Nginx, mind az Apache ellen képes veszíteni.
A grafikonok összes görbületét vasborításúan reprodukáljuk.
Valamiféle következtetés:
Igen, az Apache rosszabbul működik 1 és 8 magon, de egy kicsit jobban működik 4-en.
Igen, a 8 magos Nginx egymás után jobban feldolgozza a kéréseket, 1 és 4 magon, és rosszabbul működik, ha sok kapcsolat van.
Igen, az IIS a 4 magot részesíti előnyben a többszálú munkaterheléseknél, és a 8 magot részesíti előnyben az egyszálú munkaterheléseknél. Végső soron az IIS valamivel gyorsabb volt mindenkinél 8 magon nagy terhelés mellett, bár minden szerver egyenrangú volt.
Ez nem mérési hiba, itt a hiba nem több, mint +-1ms. késésekben és legfeljebb +- 2-3 kérés másodpercenként az RPR esetében.
Az eredmények, ahol 8 mag rosszabbul teljesít, egyáltalán nem meglepő, a sok mag és az SMT/Hyperthreading nagymértékben rontja a teljesítményt, ha van időkeretünk, amely alatt a teljes folyamatot teljesítenünk kell.
Forrás: will.com