Puhuimme metodologiasta artikkelissa, tässä testaamme HTTPS:ää, mutta realistisemmissa skenaarioissa. Testausta varten saimme Let's Encrypt -sertifikaatin ja otimme käyttöön Brotli-pakkauksen arvoon 11.
Tällä kertaa yritämme toistaa skenaarion, jossa palvelin otetaan käyttöön VDS:llä tai virtuaalikoneena isännässä, jossa on tavallinen prosessori. Tätä tarkoitusta varten rajaksi asetettiin:
- 25% - mikä vastaa taajuutta ~ 1350 MHz
- 35 % -1890 MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Kertayhteyksien määrää on vähennetty 500:sta 1, 3, 5, 7 ja 9:ään,
tulokset:
Viiveet:
TTFB sisällytettiin erityisesti erilliseksi testiksi, koska HTTPD Tools luo uuden käyttäjän jokaiselle yksittäiselle pyynnölle. Tämä testi on vielä varsin irrallaan todellisuudesta, koska käyttäjä klikkaa silti pari sivua ja todellisuudessa TTFP on pääroolissa.
Ensimmäinen, yleensä aivan ensimmäinen pyyntö IIS-virtuaalikoneen ensimmäisen käynnistyksen jälkeen kestää keskimäärin 120 ms.
Kaikki myöhemmät pyynnöt osoittavat 1.5 ms:n TTFP:n. Apache ja Nginx ovat jäljessä tässä suhteessa. Henkilökohtaisesti kirjoittaja pitää tätä testiä paljastavimpana ja valitsisi voittajan vain sen perusteella.
Tulos ei ole yllättävä, koska IIS tallentaa välimuistiin jo pakatun staattisen sisällön eikä pakkaa sitä joka kerta, kun sitä käytetään.
Asiakasta kohden käytetty aika
Suorituskyvyn arvioimiseksi riittää testi yhdellä liitännällä.
Esimerkiksi IIS suoritti 5000 käyttäjän testin 40 sekunnissa, mikä on 123 pyyntöä sekunnissa.
Alla olevat kaaviot näyttävät ajan, jonka jälkeen sivuston sisältö on siirretty kokonaan. Tämä on tiettynä aikana suoritettujen pyyntöjen osuus. Meidän tapauksessamme 80 % kaikista pyynnöistä käsiteltiin 8 millisekunnissa IIS:ssä ja 4.5 ms:ssa Apachella ja Nginxillä, ja 8 % kaikista pyynnöistä Apachessa ja Nginxissä käsiteltiin jopa 98 millisekunnissa.
Aika, jona 5000 pyyntöä käsiteltiin:
Aika, jona 5000 pyyntöä käsiteltiin:
Jos sinulla on virtuaalikone, jossa on 3.5 GHz:n prosessori ja 8 ydintä, valitse haluamasi. Kaikki verkkopalvelimet ovat hyvin samankaltaisia tässä testauksessa. Kerromme alla, mikä verkkopalvelin valita kullekin isännälle.
Mitä tulee hieman realistisempaan tilanteeseen, kaikki verkkopalvelimet menevät vastakkain.
suoritusteho:
Kaavio viiveistä verrattuna samanaikaisten yhteyksien määrään. Tasaisempi ja matalampi on parempi. Viimeiset 2 % poistettiin kaavioista, koska ne tekisivät niistä lukukelvottomia.
Harkitse nyt vaihtoehtoa, jossa palvelinta isännöidään virtuaalisessa isännöinnissä. Otetaan 4 ydintä 2.2 GHz:llä ja yksi ydin 1.8 GHz:llä.
Kuinka skaalata
Jos olet koskaan nähnyt, miltä tyhjiötriodien, pentodien ja niin edelleen virta-jännite-ominaisuudet näyttävät, nämä kaaviot ovat sinulle tuttuja. Tämä on se, mitä yritämme saada kiinni - kylläisyys. Raja on se, kun heittäisit kuinka monta ydintä tahansa, suorituskyvyn kasvu ei ole havaittavissa.
Aiemmin koko haasteena oli käsitellä 98 % pyynnöistä pienimmällä viiveellä kaikille pyynnöille, pitäen käyrä mahdollisimman tasaisena. Nyt, rakentamalla toinen käyrä, löydämme kullekin palvelimelle optimaalisen toimintapisteen.
Otetaan tätä varten Pyynnöt sekunnissa (RPR) -osoitin. Vaaka on taajuus, pystysuora on sekunnissa käsiteltyjen pyyntöjen määrä, rivit ovat ytimien lukumäärä.
Näyttää korrelaation siitä, kuinka hyvin Nginx käsittelee pyynnöt peräkkäin. 8 ydintä toimii paremmin tässä testissä.
Tämä kaavio osoittaa selvästi, kuinka paljon paremmin (ei paljon) Nginx toimii yhdessä ytimessä. Jos sinulla on Nginx, sinun tulee harkita ytimien määrän vähentämistä yhteen, jos isännöit vain staattisia.
Vaikka IIS:llä on alhaisin TTFB Chromen DevToolsin mukaan, se onnistuu häviämään sekä Nginxille että Apachelle vakavassa taistelussa Apache Foundationin stressitestin kanssa.
Kaikki kaavioiden kaarevuus toistetaan rautapäällysteisinä.
Jonkinlainen johtopäätös:
Kyllä, Apache toimii huonommin 1- ja 8-ytimisessä, mutta toimii hieman paremmin 4-ytimisessä.
Kyllä, Nginx 8 ytimellä käsittelee pyynnöt paremmin peräkkäin, 1 ja 4 ytimessä, ja toimii huonommin, kun yhteyksiä on paljon.
Kyllä, IIS suosii 4 ydintä monisäikeisissä työkuormissa ja 8 ydintä yksisäikeisissä työkuormissa. Loppujen lopuksi IIS oli hieman nopeampi kuin kaikki muut 8 ytimessä suurella kuormituksella, vaikka kaikki palvelimet olivatkin tasavertaisia.
Tämä ei ole mittausvirhe, tässä virhe on enintään +-1 ms. viiveissä ja enintään +- 2-3 pyyntöä sekunnissa RPR:lle.
Tulokset, joissa 8 ydintä toimivat huonommin, eivät ole ollenkaan yllättäviä, monet ytimet ja SMT/Hyperthreading heikentävät suorituskykyä suuresti, jos meillä on aikakehys, jossa meidän on suoritettava koko liukuhihna.
Lähde: will.com