Tiivistelmä
Tutkimus toteutettiin kevään 2019 aikana osana Tutkimusprosessit-kurssia. Tavoitteena oli selvittää vapaan ohjelmiston HTTP-kiihdyttimien vaikutusta staattisten ja dynaamisten verkkosivustojen suorituskykyyn. Tutkimuksessa keskityttiin suorituskyvyn kilpailuttamiseen kolmen HTTP-kiihdyttimen osalta, joiden ominaisuudet ja lisensointi vastasivat tutkimuksen vaatimuksia.
Tutkimusraportin tietoperustassa tutustutaan vapaan ohjelmiston kriteereihin, HTTP-kiihdyttimien, välimuistituksen ja erilaisten välityspalvelimien toimintaan, sekä aiheesta aiemmin tehtyjen tutkimusten tuloksiin. Tietoperustan lopussa esitellään lyhyesti tutkimukseen valitut kolme HTTP-kiihdytintä: Varnish, Squid ja Nginx.
Aineisto ja tutkimusmenetelmät -osiossa kuvataan, miten testausympäristö luotiin ja millä perustein. Testit suoritettiin kokonaan lähiverkon sisällä palvelin- ja client-tietokoneella, joiden kokoonpanojen konfiguraatiot kuvataan raportin liitteissä yksityiskohtaisesti. Esitettyjen tietojen pohjalta tutkimus onkin tarvittaessa toistettavissa lähes identtisin tuloksin. Osion lopussa kuvataan, mitä dataa eri palvelinkokoonpanojen suorituskyvyn mittaamisessa kerättiin, miten se kerättiin ja kuinka sitä käsiteltiin lopullisten tulosten saamiseksi.
Tulosten pohjalta havaittiin, että verkkosivusisältöjen välimuistittamisesta on suhteellista hyötyä sekä staattisten että dynaamisten verkkosivujen kanssa. Kaiken kaikkiaan parhaimmaksi vapaan ohjelmiston HTTP-kiihdyttimeksi suoriutui Nginx. Heikoiten pärjäsi Squid, vaikkakin se oli ylivoimaisesti tehokkain tilanteissa, joissa HTTP-pyyntöjä ei samanaikaistettu. Yleisimmissä käyttötilanteissa, suositukseni kohdistuu kuitenkin Nginx- ja Varnish-kiihdyttimiin dynaamisten verkkosivujen kiihdyttämisessä.
Lopuksi raportissa tarkastellaan tutkimuksen onnistumista sen tulosten ja tutkimuksessa tehtyjen päätösten osalta. Siinä huomioidaan tutkimuksen aikana tehdyt virheet, jotta ne voidaan välttää vastaavissa tutkimuksissa myöhemmin. Lisäksi esitän suositukseni tulosten hyödyntämiselle ja jatkotutkimuksille.
Huomio
Tässä verkkojulkaisussa kuvaan ainoastaan tutkimusraportin aineisto ja tutkimusmenetelmät, tulokset sekä johtopäätökset ja suositukset. Tutkimuksen tietoperusta löytyy alkuperäisestä tutkimusraportista:
Tutkimusraportti – Markus Pyhäranta
Tutkimusraportin liite 1 – Tutkimustulokset taulukkotiedostona
Tekniset tiedot tutkimuksen testausympäristöstä:
- Oletuskonfiguraation ja testausympäristön asennus
- Varnish asennus ja konfigurointi
- Squid asennus ja konfigurointi
- Nginx asennus ja konfigurointi
Aineisto ja tutkimusmenetelmät
Fyysinen testausympäristö ja ohjelmistot
Dynaamisina verkkosivuina käytettiin paikallista kopiota markuspyharanta.com WordPress-blogista. Staattiset sivut tehtiin MIT-lisensoidun Landing Page -Bootstrap-teeman pohjalta. (Start Bootstrap 2014). Molemmat sivut toimivat testauksessa vakiona, eivätkä ne muuttuneet palvelinohjelmistosta riippumatta. Staattinen sivu oli kooltaan 8929 bittiä ja dynaaminen sivu 51241 bittiä. Jotta WordPress-pohjainen sivu saatiin toimimaan lähiverkossa oikein, nimipalvelun toimintaa simuloitiin sekä palvelimen että clientin päässä hosts-tiedostolla. Palvelimella isäntänimi markusproto.fi osoitettiin palvelimen localhost-osoitteeseen, kun taas client-tietokoneella markusproto.fi osoitettiin palvelimen sisäverkon IP-osoitteeseen 192.168.1.8.
Palvelintietokoneen virkaa toimitti Lenovo ThinkPad T480 -kannettava (I5-8250U, 16GB RAM, Gigabit ethernet). Vakiona konfiguraatiossa oli LAMP-pino, joka koostui Xubuntu 18.04.1 LTS -käyttöjärjestelmästä, Apache 2.4.38 www-palvelinohjelmistosta, MariaDB 10.3.12 -tietokannasta ja PHP 7.3.1 ohjelmointikielestä. Apache asennettiin kuuntelemaan porttia 8080 ja vaihdettiin mpm_prefork -modulista mpm_worker -moduliin. Modulin konfiguraatio muokattiin mahdollistamaan jopa 1000 samanaikaista yhteydenottoa. Myös PHP optimoitiin suorituskykyisemmäksi PHP-FPM FastCGI prosessimanagerilla.
Muuttujina toimivat lopulliseen testaukseen valitut kolme HTTP-kiihdytinohjelmistoa, jotka olivat täyttäneet niille alustavassa arvioinnissa esiasetetut kriteerit. Valitut HTTP-kiihdyttimet, Varnish 5.2.1, Squid 3.5.27 ja Nginx 1.14.0, asennettiin palvelintietokoneelle kuuntelemaan porttia 80. Ohjelmistot testattiin vuorotellen siten, että vain yhden ohjelmiston palvelut olivat aktiivisesti käynnissä palvelinkoneella. Muut HTTP-kiihdyttimet eivät samanaikaisesti kuluttaneet järjestelmäresursseja, tai vaikuttaneet sisällön välimuistittamiseen. Kunkin ohjelmiston konfiguraatiotiedostot ja asennusvaiheet ovat tämän tutkimusraportin liitteissä 2-15. Sekä Apachea että HTTP-kiihdyttimiä ajettiin kaikilla neljällä prosessoriytimellä, ilman rajoituksia.
Rasitustestauksessa käytettiin tehokasta pöytäkonetta (I7-6700K, 16GB RAM, Gigabit Ethernet). Testaustyökaluna toimi koko tutkimuksen ajan ab-ohjelmaa, joka on suunniteltu Apache www-palvelimen suorituskyvyn arviointiin. (Apache 2019).
Molempia tietokoneita varten tarvittavat ohjelmat asennettiin suoraan raudan ja käyttöjärjestelmän päälle, ilman virtualisointia. Lisäksi koneet olivat sisäverkossa kiinni Zyxel GS-108B v3 -kytkimessä, joka tuki koneiden verkkokorttien tavoin gigabitin verkkoyhteyksiä. (Zyxel 2019). Tutkimus toteutettiinkin paikallisessa lähiverkossa, josta ei ollut pääsyä julkiseen internettiin. Tähän oli neljä syytä:
- Testauksessa käytetyt rasitustyökalut ovat tulkittavissa palvelunestohyökkäykseksi. Testattaessa palvelinohjelmistojen kykyä tarjoilla verkkosisältöä, sivuja ladattiin samanaikaisesti satoja kertoja. Tämä simuloi realistista tilannetta, jossa sivustolla vierailisi oikeita käyttäjiä. Lailliset ja eettiset ongelmat vältettiin toteuttamalla tes-tausympäristö puhtaasti sisäverkon sisään. Yhteys julkiseen verkkoon oli auki ainoastaan palvelin- ja muiden ohjelmistopakettien asennusvaiheessa.
- Sisäverkossa vältettiin vaikeammin ennakoitavat pullonkaulat verkkoyhteyksissä. Vaikka testausta suorittavan client-tietokoneen ja pilvessä olevan virtuaalipalvelimen yhteyksissä ei olisikaan ollut vikaa, mikään ei olisi taannut, etteikö yhteysongelmia olisi voinut olla jossain niiden välillä. Testaus julkisessa verkossa olisi toki ollut lähempänä realismia, mutta muuttujia ja mahdollisia rajoittavia tekijöitä olisi myös ollut liikaa, jotta vertailusta olisi saatu kaikkien ohjelmistojen osalta reilu.
- Kustannustehokkuus. Sisäverkossa testaaminen ei maksanut mitään, jolloin tutki-muksen kustannuksiksi tuli nolla euroa laitteiston ollessa jo valmiina.
- Lähiverkossa testaaminen ilman julkista verkkoyhteyttä varmisti, ettei kaistaa kulunut muihin internet-yhteydestä riippuviin prosesseihin. Tällöin koko verkon kapasi-teetti oli testauksessa käytettyjen työkalujen käytössä.
Kuva 1. Testausverkon arkkitehtuurikuvaus.
Aineiston keruu
Tutkimuksessa kerättiin ensin pohjatulokset Apache www-palvelimen suorituskyvystä ilman HTTP-kiihdytintä. Ab-ohjelman syntaksi oli seuraavanlainen, jossa parametri -n viittaa yhteydenottojen kokonaismäärään ja -c samanaikaisten yhteydenottojen määrään:
ab -n $requests -c $concurrency http://markusproto.fi/ > /home/markus/default/static/n$requestsc$concurrency.csv
Kussakin testissä suorituskykyä mitattiin ab-ohjelmalla eri parametriarvoin. Ensin testattiin pelkällä -n -parametrilla, jonka jälkeen komentoon lisättiin parametri -c siten, että yhteydenottojen kokonaismäärän ja samanaikaisten yhteydenottojen suhde oli 5:1. (Taulukko 1).
Taulukko 1. Ab-ohjelmalla suoritetut testit.
Tulokset vietiin suoraan CSV-tiedostossa testikäyttäjän kotihakemistossa sijaitseviin static tai dynamic -kansioihin, riippuen kumpaa sivua testattiin.
Näin saatiin oletusarvot Apache www-palvelinohjelmiston suorituskyvystä. Seuraavaksi suorituskykyä mitattiin samoilla testeillä eri HTTP-kiihdyttimien kanssa. Järjestys, jossa kiihdyttimiä testattiin, oli seuraava: Varnish > Squid > Nginx. Lopulta tutkimuksessa oli siis suoritettu testit siten, että kahden sivun suorituskykyä mitattiin neljällä eri palvelinkokoonpanolla ja 12:lla eri komennolla. Täten tutkimuksen aikana muodostui yhteensä 96 CSV-tiedostoa dataa. Dataa käsiteltiin lopulliseen muotoon, jonka jälkeen ne yhdistettiin yhdeksi isoksi Excel-taulukoksi, joka löytyy raportin liitteestä 1.
Tulokset
HTTP-kiihdyttimien suorituskykyä testattiin 12 testillä taulukon 1 mukaisesti. Testien tarkat tulokset löytyvät raportin liitteestä 1. Jokaisen kiihdyttimen tuloksia verrattiin prosentuaalisesti oletuskonfiguraation suorituskykyyn. Tulosten esittämisen helpottamiseksi, prosenttiosuuksista laskettiin keskiarvo.
Staattiset sivut
Tutkimustulokset osoittivat, että staattisten sivujen kohdalla, Squid HTTP-kiihdytin suoriutui keskiarvoisesti parhaiten tilanteissa, joissa HTTP-pyyntöjä ei tehty samanaikaisesti. Squid ei kuitenkaan pärjännyt testeissä, joissa pyyntöjä samanaikaistettiin. Niissä parhaat tulokset jakautuivat Nginxin ja Varnishin kesken. Erot oletuskonfiguraation (ei HTTP-kiihdytintä) eivät kuitenkaan olleet kovin suuria (keskiarvo alle 11%).
Testeihin kulunut kokonaisaika
Tarkastelemalla testeihin kulunutta kokonaisaikaa, kun pyyntöjen samanaikaisuutta ei otettu huomioon, Squid käsitteli HTTP-pyynnöt keskimäärin 26,8% nopeammin verrattuna oletuskonfiguraatioon. Seuraavana oli Nginx 20,72% nopeammin ja viimeisenä Varnish, joka käsitteli pyynnöt 10,61% hitaammin, kuin oletuskonfiguraatio. Samanaikaisuuden kanssa Nginx oli oletuskokoonpanoa 7,39% nopeampi, Varnish 2,85% nopeampi ja Squid 62,44% hitaampi.
Käsiteltyjen pyyntöjen lukumäärä sekunnissa
Tarkastelemalla käsiteltyjen pyyntöjen lukumäärää sekunnissa, ilman pyyntöjen samanaikaisuutta, Squid käsitteli sekunnissa pyyntöjä keskimäärin 37,01% enemmän, kuin oletuskonfiguraatio. Seuraavana oli Nginx 26,43% parannuksella, ja viimeisenä Varnish, jonka käsittelemien pyyntöjen lukumäärä oli 8,87% huonompi verrattuna oletuskonfiguraation. Testeissä, joissa huomioitiin samanaikaisuus, Varnish pärjäsi parhaiten käsittelemällä pyyntöjä 9,87% enemmän. Seuraavana oli Nginx 8,79%:n parannuksella ja viimeisenä Squid, joka käsitteli pyyntöjä sekunnissa 31,96% vähemmän.
Siirtonopeus
Siirtonopeudessa parhaiten suoriutui Squid 38,89% parannuksella oletukseen, kun testeissä ei huomioitu pyyntöjen samanaikaisuutta. Seuraavana oli Nginx 26,7%:lla ja viimeisenä Varnish, jonka siirtonopeudet olivat keskiarvoisesti 8,15% oletuskonfiguraatiota huonommat. Samanaikaisuus huomioiden, Varnish oli paras parantaen tuloksia 10,76%:lla. Seuraavaksi tuli Nginx 9,03% parannuksella, ja viimeiseksi Squid, jonka siirtonopeudet olivat 31,02% huonommat.
HTTP-pyyntöön käytetyn ajan keskiarvo
Ab:n tulokset sisältävät kaksi arvoa, joilla mitattiin yhteen pyyntöön käytettyä aikaa millisekunteina. Kun testi (-n 1000) ei sisällä samanaikaisuutta, arvot ovat identtiset:
Time taken for tests: 1.308 seconds Time per request: 1.308 [ms] (mean) Time per request: 1.308 [ms] (mean, across all concurrent requests)
Samanaikaisuuden (-n 1000 -c 200) kanssa niillä on kuitenkin eroa. Esimerkiksi:
Time taken for tests: 0.088 seconds Time per request: 17.539 [ms] (mean) Time per request: 0.088 [ms] (mean, across all concurrent requests)
Ensimmäinen arvo, Time per request (mean), kuvaakin aikaa, joka keskimäärin kuluu yksittäisen pyynnön käsittelyyn, jos se olisi suoritettu ilman samanaikaisuutta, tai pikemminkin eristetyssä ympäristössä nykyisellä samanaikaisuudella. Käytännössä se kuvaa parhaiten yhden pyynnön käsittelyn viivettä. (ServerFault 2011). Tällä osa-alueella parhaiten pärjäsi Squid 26,73% parannuksella, kun samanaikaisuutta ei huomioitu. Seuraavana oli Nginx 20,37% ja viimeisenä Varnish 10,76% hitaampana. Samanaikaisuus huomioiden, Nginx voitti 5,74% oletusta nopeampana, sitten Varnish 1,41% tuloksella ja viimeisenä Squid, joka oli 63,96% hitaampi.
Toinen arvo, Time per request (mean, across all concurrent requests), taas kuvaa paremmin suorituskykyä. (ServerFault 2011). Esimerkin mukaisesti, yksittäisen pyynnön käsittelyyn meni samanaikaiset pyynnöt sallittaessa 0,088 ms, joka on nopeampi, kuin 1,308 ms. Pyyntöjen samanaikaistaminen on siis nopeampaa, kuin niiden käsitteleminen yksitellen. Ilman samanaikaisuutta, Squid oli nopein 26,73% parannuksella oletuskonfiguraatioon. Seuraavana oli Nginx 20,37% parannuksella ja viimeisenä Varnish 10,76% heikommalla tuloksella. Kuitenkin samanaikaisuuden kanssa Nginx voitti 5,74% paremmalla suorituskyvyllä. Varnish suoriutui 1,54% paremmin ja Squid 63,88% hitaammin.
Pelkistetyt tulokset
Kun staattisen verkkosivun suorituskykyä testattiin ilman samanaikaisia HTTP-pyyntöjä, Squid-kiihdyttimen suorituskyky oli ylivoimaisesti paras. Samanaikaisuuden kanssa, tulokset jakautuivat Nginxin ja Varnishin kesken, joista Nginx oli keskiarvon perusteella tehokkaampi. (Taulukko 2.)
Taulukko 2. Parhaat HTTP-kiihdyttimet staattisten sivujen suorituskyvyn parantamiseen.
Dynaamiset sivut
Tutkimustulokset osoittivat, että Nginx tarjoili dynaamiset WordPress-sivut keskiarvoisesti tehokkaimmin. Kun HTTP-pyyntöjä ei samanaikaistettu, Nginx voitti kaikki suoritetut testit. Samanaikaisuuden kanssa, testien parhaat tulokset jakautuivat tasaisesti Nginxin ja Varnishin välille. Kun tuloksia verrattiin prosentuaalisesti oletuskonfiguraatioon, Nginx oli kuitenkin keskiarvon perusteella parempi.
Testeihin kulunut kokonaisaika
Tarkastelemalla testeihin kulunutta kokonaisaikaa, kun pyyntöjen samanaikaisuutta ei otettu huomioon, Nginx käsitteli HTTP-pyynnöt keskimäärin 96,49% nopeammin verrattuna oletuskonfiguraatioon. Seuraavana oli Squid 95,49% nopeammin ja viimeisenä Varnish 94,58% parannuksella oletuskonfiguraatioon nähden. Samanaikaisuuden kanssa Nginx oli oletuskokoonpanoa 95,71% nopeampi, Varnish 95,41%, ja Squid 95,24%. Tulokset olivat siis kaikki hyvin lähellä toisiaan.
Käsiteltyjen pyyntöjen lukumäärä sekunnissa
Tarkastelemalla käsiteltyjen pyyntöjen lukumäärää sekunnissa, ilman pyyntöjen samanaikaisuutta, Nginx käsitteli pyyntöjä keskimäärin huimat 2751,71% enemmän, kuin oletuskonfiguraatio. Seuraavaksi tuli Squid 2115,06% parannuksella, ja viimeisenä Varnish, jonka käsittelemien pyyntöjen lukumäärä oli 1743,95% suurempi verrattuna oletuskonfiguraation. Testeissä, joissa pyyntöjen samanaikaisuus huomioitiin, Nginx pärjäsi parhaiten käsittelemällä pyyntöjä 2246,22% enemmän. Seuraavana oli Varnish 2174,78%:n parannuksella ja viimeisenä Squid, joka käsitteli sekunnissa pyyntöjä 2083,93% oletuskonfiguraatiota enemmän.
Siirtonopeus
Siirtonopeudessa parhaiten suoriutui Nginx 2523,24%:n parannuksella oletukseen, kun testeissä ei huomioitu pyyntöjen samanaikaisuutta. Seuraavana oli Squid 1943,39%:lla ja viimeisenä Varnish, jonka siirtonopeudet olivat keskiarvoisesti 1599,33% oletuskonfiguraatiota paremmat. Samanaikaisuus huomioiden, Nginx oli paras parantaen tuloksia 2058,37%:lla. Seuraavaksi tuli Varnish 1996,48% parannuksella, ja viimeiseksi Squid, jonka siirtonopeudet olivat 1914,76% oletusta paremmat.
HTTP-pyyntöön käytetyn ajan keskiarvo
Kuten tutkimusraportin osiossa 4.1.4 esitettiin, Ab-työkalu antaa kaksi eri arvoa HTTP-pyyntöön käytetylle ajalle. Tarkasteltaessa ensimmäistä Time per request (mean) arvoa, kun samanaikaisuutta ei huomioitu, Nginx käsitteli pyynnöt keskiarvoisesti 96,48% oletuskonfiguraatiota nopeammin. Seuraavaksi tuli Squid 95,48%:n parannuksella ja viimeisenä Varnish 94,57% oletusta nopeampana. Samanaikaisuus huomioiden, Nginx paransi oletuskonfiguraation tuloksia 95,67%, Varnish 95,42% ja Squid 95,23%.
Toisen ”Time per request (mean, across all concurrent requests)” -arvon perusteella, kun samanaikaisuutta ei huomioitu, Nginx oli taas nopein 95,67%:n parannuksella oletuskonfiguraatioon. Seuraavana oli Squid 95,48%:n parannuksella ja viimeisenä Varnish 94,57% oletusta paremmalla tuloksella. Samanaikaisuuden kanssa Nginx voitti taas 95,67% nopeammalla tuloksella. Varnish suoriutui 95,42% oletusta paremmin ja Squid 95,23% nopeammin.
Pelkistetyt tulokset
Kun dynaamisen verkkosivun suorituskykyä testattiin ilman samanaikaisia HTTP-pyyntöjä, Nginx-kiihdyttimen suorituskyky oli ylivoimaisesti paras. Nginx johti tuloksia myös samanaikaisuuden kanssa, vaikkakin Varnish voitti joitain yksittäisiä testejä. Loppuen lopuksi, Nginx oli kuitenkin keskiarvon perusteella tehokkain kaikilla osa-alueilla. (Taulukko 3.)
Taulukko 3. Parhaat HTTP-kiihdyttimet dynaamisten sivujen suorituskyvyn parantamiseen.
Johtopäätökset ja suositukset
Tutkimus osoitti, että verkkosivusisältöjen välimuistittamisesta on suhteellista hyötyä sekä staattisten että dynaamisten verkkosivujen kanssa. Kaiken kaikkiaan parhaimmaksi vapaan ohjelmiston HTTP-kiihdyttimeksi suoriutui Nginx.
Jos tarkoituksena on nopeuttaa staattisia verkkosivuja HTTP-kiihdyttimellä, suosittelen Nginxin asentamista välimuistittavaksi, käänteiseksi välityspalvelimeksi. Vaihtoehtoisesti Varnish on myös hyvä ja helpommin konfiguroitava vaihtoehto. Jos taas keksii käyttötarkoituksen, jossa staattista sisältöä ladataan paljon ilman pyyntöjen samanaikaisuutta, Squid on suorituskyvyltään ylivoimaisesti paras.
Tulee kuitenkin huomioida, että testeissä osoitetut staattisten sivujen latausnopeudet eivät vastaa oikeaa tilannetta, jossa käyttäjä vierailee sivustolla. Verkkoselaimet hyödyntävät myös omaa välimuistiaan, ja staattisen sivun lataaminen on aina nopeampaa sieltä, kuin HTTP-kiihdyttimen välimuistista. Siksi koenkin, ettei HTTP-kiihdyttimistä ole tarpeeksi hyötyä staattisten sivujen kohdalla, jotta sellaisen käyttöönotto olisi välttämättä kannattavaa. Realistisessa käyttötarkoituksessa palvelin joutuu käsittelemään useita HTTP-pyyntöjä (kävijöitä) samanaikaisesti. Tällöinkin Nginx käsitteli pyynnöt vain alle 6% oletuskonfiguraatiota nopeammin.
HTTP-kiihdyttimien hyödyt dynaamisten verkkosivujen tarjoamisessa, ovat kuitenkin selvät. Suosittelen Nginxiä myös dynaamisen sisällön suorituskyvyn parantamiseen. Varnish pärjäsi myös ihan hyvin yksittäisissä testeissä, joissa samanaikaisten yhteydenottojen määrät olivat 20-100 välillä. Nginx oli kuitenkin tehokkaampi sitä suuremmilla ja pienemmillä määrillä HTTP-pyyntöjä. Sen tulosten keskiarvot olivat parhaat kaikkien Ab-testien mittausyksikköjen osalta. Raskaimmassakin testissä (2500 pyyntöä, joista 500 suoritettiin samanaikaisesti), Nginx tarjoili dynaamiset WordPress sivut noin 24 kertaa nopeammin, kuin oletuskonfiguraatio, jossa ei ollut välimuistittavaa HTTP-kiihdytintä.
Tuloksia tarkasteltaessa, tulee kuitenkin huomioida, etteivät tutkimuksen tulokset vastaa realistisessa ympäristössä odotettavia tuloksia. Oikea www-palvelin tavoitettaisiin internetin välityksellä, jolloin viive on huomattavaa verrattuna yhden gigabitin lähiverkkoon. Tutkimuksen pohjalta ei siis voida suoraan sanoa, kuinka paljon kiihdytin nopeuttaa pilvessä ylläpidettyä VPS-palvelinta, mikä ei toisaalta ollutkaan tutkimuksen tavoitteena. Tulokset pikemminkin osoittavat, kuinka tutkimuksessa testatut kolme HTTP-kiihdytintä sijoittuvat suorituskyvyssä toisiinsa nähden.
Oleellinen tekijä testausympäristön konfiguroimisessa oli saada Apache sallimaan vähintään 500 samanaikaista yhteydenottoa. Rajoitus vaikutti nimittäin oleellisesti oletuskonfiguraation suorituskyvyn mittaamiseen, ja täten olisi voinut väärin konfiguroituna vääristää eri HTTP-kiihdytin kokoonpanojen tuloksia suhteessa oletuskonfiguraatioon.
Tutkimuksessa tapahtui kuitenkin valitettava vastaava virhearviointi, sillä MariaDB-tietokannalla on myös rajoitus samanaikaisten yhteydenottojen määrästä. Tätä rajoitusta ei ymmärretty muokata, jolloin samanaikaiset pyynnöt tietokannasta oli rajoitettu oletukseen, eli 151 pyyntöön. (MariaDB 2019). Näin ollen, tutkimustulokset vääristyivät dynaamisten verkkosivujen suorituskyvyn osalta, koska samanaikaisia yhteydenottoja ei pystytty kaikissa testeissä suorittamaan määrätyn muuttujan mukaisesti. Virhe on siis vaikuttanut niihin kahteen testiin, joissa oletuskonfiguraation suorituskykyä ladata dynaamisia sivuja mitattiin yli 151 samanaikaisella tietokantapyynnöllä (-n 1000 -c 200 ja -n 2500 -c 500).
Esimerkiksi, kun tarkastellaan testeihin kulunutta kokonaisaikaa viivadiagrammissa, Varnishin, Squidin ja Nginxin käyrät nousevat paljon lineaarisemmin verrattuna oletuskonfiguraatioon, joka taas lähtee jyrkkään kasvuun joskus 100:n samanaikaisen pyynnön jälkeen.
Kuva 2. Testeihin käytetty aika sekunteina.
Virhe ei vaikuttanut HTTP-kiihdyttimillä suoritettuihin testeihin, sillä niissä sivut ladattiin kiihdyttimen välimuistista, eikä tietokantapyyntöjä tehty. Se kuitenkin vääristi niitä prosentuaalisia arvoja, joilla kiihdyttimien suorituskykyä verrattiin oletuskonfiguraatioon nähden.
Tässä tutkimuksessa käytetyt HTTP-kiihdytin konfiguraatiot eivät kuitenkaan ole suoraan hyödynnettävissä realistisiin ympäristöihin, sillä niissä ei huomioida esimerkiksi välimuistin tyhjentämisen käytännöllisyyttä tosielämän tilanteissa. Tyypillisesti siihen pitäisi olla helppo ratkaisu esimerkiksi sisällönhallintajärjestelmän kautta, eivätkä nämä tulokset ota siihen kantaa millään tavalla. Kiihdyttimet konfiguroitiin suoraan tutkimuksen tarpeisiin, eikä oikeasti verkkosivujen aktiiviseen ylläpitoon. Kunkin kiihdyttimen konfiguraatiot ovat paremmin optimoitavissa yksilöllisiin käyttötarkoituksiin, mutta ne toimivat sellaisenaan hyvänä pohjana muokkauksille.
Aiheen tutkimusalue ei kuitenkaan jää tähän, sillä tutkimuksen pohjalta herää uusia kysymyksiä. Nykyinen trendi on siirtymässä HTTPS-protokollaan myös yksinkertaisten sivujen käytössä. Google Chrome on jo vuoden 2018 heinäkuusta saakka merkannut kaikki tavallista HTTP-protokollaa käyttävät sivustot ”ei turvalliseksi”. (Google Security Blog 2018). Tukevatko tutkimuksessa testatut HTTP-kiihdyttimet myös suojattua protokollaa, ja vaikuttaako se eri tavalla niiden suorituskykyyn? Jos eivät toimi, niin mitä vaaditaan TLS-yhteyden muodostamiseksi? Ainakin Nginx tukee itsessään SSL/TLS-protokollaa, mutta esimerkiksi Varnishin kanssa tulisi ilmeisesti integroida vielä erillinen TLS-proxy, jotta HTTPS-yhteyden kiihdyttäminen olisi mahdollista. Hitch on Varnish Softwaren kehittämä välityspalvelin juuri tähän tarkoitukseen, eli SSL/TLS:n terminointiin. Lisäksi, miten nämä teknologiat skaalautuvat laajempiin infrastruktuureihin, joissa hyödynnetään kuormantasausta (load balancing)?
Näihin kysymyksiin voidaan etsiä vastauksia tutkimustulosten pohjalta. Ensin kuitenkin suorittaisin korjaavat testit tästä tutkimuksesta, jossa MariaDB:n rajoitukset otettaisiin huomioon. Tekisin myös enemmän testejä HTTP-pyyntöjen samanaikaisuudella, enkä antaisi yhtä paljon arvoa testeille, joissa sitä ei ollut. Lisäksi, nostaisin samanaikaisten pyyntöjen lukumääriä. Suorittaisin kunkin testin vähintään kolme kertaa, joista sitten laskisin testin osalta keskiarvon. Siihen ei kuitenkaan lähdetty tässä tutkimuksessa, jotta datamäärät pidettäisiin hallinnassa tutkimuksen aikataulu huomioon ottaen. Samalla olisin myös halunnut seurata palvelinresurssien kuormaa testien aikana, jotta lähtökohdat tuloksille olisivat mahdollisimman yhtenäiset kussakin testissä. Tutkimukseen voisi myös lisätä HTTP-kiihdyttimeksi Apache www-palvelimen, joka on Nginxin tavoin konfiguroitavissa välimuistia hyödyntäväksi, käänteiseksi välityspalvelimeksi.
Korjaavien testien jälkeen, lähtisin ensisijaisesti testaamaan suorituskykyä HTTPS-protokollalla, jonka jälkeen tutkisin ratkaisujen skaalautuvuutta kuormantasausta hyödyntävissä infrastruktuureissa, kuten sisällönjakeluverkoissa.
Lähteet:
Apache 2019. Ab – Apache HTTP server benchmarking tool. Luettavissa: https://httpd.apache.org/docs/2.4/programs/ab.html. Luettu 10.2.2019.
Cloudflare 2019. What Is A Reverse Proxy? | Proxy Servers Explained. Luettavissa: https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/. Luettu 31.1.2019.
Copeland, G & McClain, M. 2019,1. Web Caching With Dynamic Content. IBM. Luettavissa: https://jimgray.azurewebsites.net/HPTS99/papers/Copeland_McClain.pdf. Luettu 31.1.2019.
Github 2016. LICENCE. Luettavissa: https://github.com/varnishcache/varnish-cache/blob/master/LICENSE. Luettu 23.2.2019.
Github 2019. READ ME. Luettavissa: https://github.com/squid-cache/squid. Luettu 23.2.2019.
GNU 2018. What is free software? Luettavissa: https://www.gnu.org/philosophy/free-sw.en.html. Luettu 31.1.2019.
Google Security Blog 2018. A secure web is here to stay. Luettavissa: https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html. Luettu 1.2.2019.
Karvinen 2011. Static Advantage – Could WordPress Be 400 Times Faster? Luettavissa: http://terokarvinen.com/2011/static-advantage-could-wordpress-be-400-times-faster. Luettu 31.1.2019.
MariaDB 2019. Server System Variables. Luettavissa: https://mariadb.com/kb/en/library/server-system-variables/#max_connections. Luettu 27.2.2019.
Netcraft 2018. April 2018 Web Server Survey. Luettavissa: https://news.netcraft.com/archives/2018/04/26/april-2018-web-server-survey.html. Luettu 29.1.2019.
Nginx 2019. LICENCE. Luettavissa: http://nginx.org/LICENSE. Luettu 31.1.2019.
Nginx 2019. Welcome to Nginx Wiki. Luettavissa: https://www.nginx.com/resources/wiki/. Luettu 23.2.2019.
Nginx 2019. What is Web Acceleration? Luettavissa: https://www.nginx.com/resources/glossary/web-acceleration/. Luettu 31.1.2019.
Pyhäranta 2017. Varnish-käänteisproxy ja webpalvelimen suorituskyvyn testaus ApacheBenchillä. Luettavissa: https://markuspyharanta.com/2017/05/14/varnish-kaanteisproxy-ja-apachebenchmark/. Luettu: 28.1.2019.
RFC 2616 1999, 7. Hypertext Transfer Protocol – HTTP/1.1. Luettavissa: https://www.rfc-editor.org/rfc/pdfrfc/rfc2616.txt.pdf. Luettu 31.1.2019.
Ryandel 2018. How to cache your website using NGINX Reverse Proxy and Proxy-Cache in CentOS7. Luettavissa: https://www.ryadel.com/en/nginx-reverse-proxy-cache-centos-7-linux/. Luettu 14.2.2019.
Schroeder, T., Goddard, S. & Ramamurthy, B. 2000, 44. Scalable Web Server Clustering Technologies. DigitalCommons@University of Nebraska – Lincoln. Nebraska. Luettavissa: http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1083&context=csearticles. Luettu 31.1.2019.
ServerFault 2011. Apache ab: please explain the output. Luettavissa: https://serverfault.com/questions/274252/apache-ab-please-explain-the-output. Luettu 21.2.2019.
Squid-Cache 2019. Squid: Optimising Web Delivery. Luettavissa: http://www.squid-cache.org/. Luettu 23.2.2019.
Squid-Cache Wiki 2018. What’s the legal status of Squid? Luettavissa: https://wiki.squid-cache.org/SquidFaq/AboutSquid. Luettu 31.1.2019.
Start Bootstrap 2014. Landing Page – A simple, elegant, and beautifully responsive landing page theme for Bootstrap 4 websites. Luettavissa: https://startbootstrap.com/themes/landing-page/. Luettu 10.2.2019.
Varnish-Cache 2017. Introduction to Varnish. Luettavissa: https://varnish-cache.org/intro/. Luettu 31.1.2019
Varnish Software 2018. Varnish Web Developer Wiki. Luettavissa: https://www.varnish-software.com/wiki/. Luettu 31.1.2019.
Vasilieva, I 2018. Introduction of an Advanced Caching Layer Leveraging the Varnish Technology Stack and Integrating It to the Existing Web Platform. Barcelona School of Informatics. Barcelona. Luettavissa: https://upcommons.upc.edu/bitstream/handle/2117/121674/135073.pdf?sequence=1&isAllowed=y. Luettu 31.1.2019.
W2Techs 2019. Usage statistics and market share of WordPress for websites. Luettavissa: https://w3techs.com/technologies/details/cm-wordpress/all/all. Luettu 28.1.2019.
Wenyuan, J 2018. Web cache server performance benchmark: nuster vs nginx vs varnish vs squid. Luettavissa: https://github.com/jiangwenyuan/nuster/wiki/Web-cache-server-performance-benchmark:-nuster-vs-nginx-vs-varnish-vs-squid#results. Luettu 31.1.2019.
WordPress 2019. Plugins – Browse: Popular. Luettavissa: https://wordpress.org/plugins/browse/popular/page/2/. Luettu 28.1.2019.
WSVincent 2018. Static vs Dynamic Websites: Pros and Cons. Luettavissa: https://wsvincent.com/static-vs-dynamic-websites-pros-and-cons/. Luettu 1.2.2019.
Zyxel 2019. 8-Port Desktop Gigabit Ethernet Switch. Luettavissa: https://www.zyxel.com/fi/fi/products_services/8-Port-Desktop-Gigabit-Ethernet-Switch-GS-108B-v3/. Luettu 18.2.2019.