V tem članku se bomo preizkusili v obratnem inženiringu, bi lahko rekli. Umazane roke bomo spravili pod pokrov vsakega spletnega strežnika in jih izkoriščali na načine, ki jih nihče nikoli ne bi izkoristil.
Ta test je meritev sferičnega konja v vakuumu, nič drugega kot podatki, ki so bili pridobljeni in zdaj ne vemo, kaj bi z njimi.
Metodologija
Operacijski sistem za Nginx in Apache je Ubuntu 18.04 LTS, za IIS Windows Server Core 2019. Pred testi so vsi operacijski sistemi prejeli najnovejše posodobitve od 04.12.2019. decembra XNUMX.
Testi so bili izvedeni izključno preko HTTP. Vsak spletni strežnik je zagnal isto stran, brezplačno predlogo Jekyll podjetja Codrops. . Vsak spletni strežnik je imel onemogočeno stiskanje gzip.
Test prepustnosti je bil izveden z orodji Httpd z argumenti:
ab -n 50000 -c 500 http://192.168.76.204:80/Strežniki so bili omejeni na 10, 5 in 1 odstotek jedra na 8, 4 in eno jedro. Testna miza je bil računalnik z 9900K@5400MHz, kar pomeni, da strežnik, ki prejme 10-odstotno omejitev, prejme približno 540MHz na jedro.
Preizkus TTFB je bil izveden, ko se je strežnik prvič zagnal in meril z orodjem DevTools; po prejemu rezultata je bil strežnik izklopljen in vrnjen nazaj na prejšnjo kontrolno točko, da se odpravi pojav kakršnih koli predpomnilnikov.
Tester in spletni strežnik sta bila na istem gostitelju in na istem virtualnem stikalu.
Za takojšnjo oceno diskovnega podsistema, rezultate meril uspešnosti ATTO in CrystalDIskMark, da bi imeli idejo o ozkih grlih.
Podatki vzeti iz virtualnega stroja:
Rezultati:
TTFB:
Povprečni TTFB za IIS je najmanjši, 0,5 ms, v primerjavi z 1,4 ms za Apache in 4 ms za Nginx.
Pretočnost:
Najprej poglejmo, kako dobro se vsak strežnik prilagaja glede na število jeder.
Graf prikazuje število klicev preizkuševalcev na spletni strežnik in zakasnitev. Graf prikazuje, da je NGINX obdelal 98 % vseh zahtev in spletno mesto dostavil v 20 ms ali manj. IIS, tako kot Apache, je zadnjih 5 % vseh klicev opravil v 76 ms oziroma 14 ms.
Graf prikazuje povprečni čas obdelave ene zahteve med testom izjemnih situacij.
Kot lahko vidite iz grafov, je IIS odpihnil tako Apache kot Nginx, pri čemer se je pod visoko obremenitvijo znatno upočasnil.
IIS je očitno dal prednost 4 jedrom pred XNUMX, pri čemer je pokazal nižje zakasnitve pri XNUMX, vendar tudi ni močno naklonjen enemu jedru.
NGINX se dobro prilagaja v vseh 8 jedrih in za Apache se zdi enojedrni scenarij najboljša izbira.
Razširljivost:
Nginx:
Zdaj pa poglejmo razširljivost glede na frekvenco in število jeder.
Nginx ni prestal testov z omejitvijo 1% za 4 in 1 jedra, ko je presegel 2000 zahtev, je prekinil povezavo s testerjem.
Apache:
Apache je tako kot Nginx, potem ko je obdelal 2500 zahtev, obupal in prekinil povezavo. Apache je padel na testu na 8, 4 in 1 jedru z omejitvijo 1 %, poleg tega pa tudi na testu s 5 % omejitvijo na enem jedru, kar je slabše od Nginxa
IIS:
Med preizkusi je IIS nabral ogromno čakalno vrsto zahtev, vendar je obdelal vsako od njih. Očitno ni nastavljenih nobenih časovnih omejitev za obdelavo zahtev.
Tabela prikazuje čas, potreben za dokončanje testa. Popolnoma absurdne konfiguracije testiranja so bile zavržene. Diagram prikazuje, kako zahteven je IIS, ko gre za strojno opremo, in kako čudovit je NGINX.
Razširljivost z diska:
Nginx:
Zdaj pa poglejmo razširljivost glede na frekvenco in število jeder ter hitrost diska.
Tokrat je Nginx padel na 4 testih namesto dveh.
Apache:
Apache ni opravil enakega števila testov kot zadnjič.
IIS:
IIS prikazuje skoraj enak graf, kot da ne bi bilo omejitev glede diska. Na splošno se grafika vseh strežnikov ni veliko spremenila, kar pomeni, da je vsak od njih predpomnil statične podatke v RAM in jih od tam stregel. Tu vidimo glavno ozko grlo – sam spletni strežnik.
Prezgodaj je za sklepanje na podlagi tega testiranja; HTTPS, stiskanja in HTTP/2 še nismo preizkusili s potrdilom v živo podjetja Let's Encrypt. O tem bomo govorili v naslednjem članku.
Vir: www.habr.com