Vertailuarvoja suosituimmalle palvelinpuolen Swift-viitekehykselle vs. Node.js

Muokkaa 7. lokakuuta: Checkout minun seurannani: Benchmarks for Linux (Ubuntu)

esittely

Työskentelin äskettäin Server-Side Swiftissä, ja minulta kysyttiin:

"Voiko Server-Side Swift voittaa Node.js: n?"

Swift pääkielenä kaikelle, mukaan lukien palvelin, on ollut kiehtova siitä lähtien, kun se avattiin ensin ja siirrettiin Linuxille. Monet teistä ovat varmasti yhtä uteliaita kuin minäkin, joten olen erittäin iloinen voidessani jakaa täällä tutkimukseni tulokset.

Parhaat palvelinpuolen Swift-kehykset

Kirjoittamishetkellä tärkeimmät palvelinpuolen Swift-kehykset (lueteltu GitHubin tähtijärjestyksessä) ovat:

  • Täydellinen ️7 956
  • Höyry ️5,183
  • Kitura ️4,017
  • Zewo ️1 186

Tämän viestin organisointi

Tämä asiakirja on esitetty seuraavalla tavalla:

  • Tämä nopea esittely
  • Tulosten yhteenveto
  • Metodologia
  • Yksityiskohtaiset tulokset
  • Päätelmät ja viimeiset huomautukset

Tulosten yhteenveto

Seuraava on nopea yhteenveto ensisijaisista vertailuarvoista, ja sanon tämän täällä:

Riippumatta yksittäisistä sijoituksista, kaikki nämä kehykset toimivat uskomattoman hyvin, Swift voitti jatkuvasti Node.js: ää, ja heidän kaikkien työskentely oli hauskaa.
Tämä kuva päivitettiin 1. syyskuuta 2016 korjauksella

Menetelmät ja huomautukset

Miksi käyttää blogeja & JSON: ta?

Yksinkertaisesti, blogit ovat enemmän kuin palauttavat “Hei, maailma!”, Ja JSON on erittäin yleinen käyttötapaus. Hyvät vertailuarvot tarvitsevat samanlaisen kuormituksen jokaisessa kehyksessä, ja sen piti olla hiukan enemmän kuorma, joka tulostaa kaksi sanaa näytölle.

Pidä asiat samoina

Yksi tärkeimmistä teemoista, joihin yritin pysyä, oli pitää kaikki blogit mahdollisimman samanlaisina toistensa suhteen samalla, kun kehitettiin edelleen kunkin kehyksen tyylillä ja syntaksilla. Monet rakenteista, kuten sisällöntuotanto, toistetaan sanatarkasti, niin että jokaisella kehyksellä on samat tietomallit, joiden kanssa työskennellä, mutta URL-osoitteen reitityksen kaltaiset näkökohdat ovat toisinaan selvästi erilaisia ​​sopimaan kunkin kehyksen syntaksiin ja tyyliin.

Hienoiset erot

Palvelinpuolen Swift-kehysten välillä on joitain hienoja eroja.

  • Sekä Kituralla että Zewolla on ongelmia rakennuksen kanssa, jos niiden absoluuttisissa tiedostopolkuissa on välilyöntejä. Xcodella on myös ongelmia rakentaa välilyöntejä absoluuttisissa tiedostopolkuissa missä tahansa puitteissa.
  • Zewo käyttää 05–09-a Swift-tilannekuvaa, mikä tarkoittaa, että sillä on vaikeuksia rakentaa vapautustilassa ja se on suoritettava vianetsintätilassa. Tästä syystä kaikki Zewo-testit suoritettiin Zewolla, joka rakennettiin ja käytettiin debug-tilassa (ilman julkaisuoptimointeja).
  • Staattinen tiedostojen käsittely on keskustelunaihe Server-Side Swift -kehyksissä. Vapor ja Zewo molemmat suosittelevat Nginxin käyttämistä välityspalvelimena staattisessa tiedostojen käsittelyssä, jolloin puitteet asetetaan sen takana taustaohjelman käsittelytehoksi. Täydellinen ehdottaa heidän sisäänrakennetun käsittelijänsä käyttöä, enkä ole nähnyt IBM: lle kommentteja heidän omasta näkemyksestään asiaan. Koska tämä tutkimus ei koskenut sitä, kuinka hyvin kehykset toimivat vakiintuneiden palvelinasovellusten, kuten Nginx, kanssa, staattista tiedostojen käsittelyä käytettiin natiivisti jokaisessa kehyksessä. Saatat pystyä saavuttamaan paremman suorituskyvyn sekä Vaporissa että Zewossa, jos päätät rakentaa tätä ajatellen. Tämä on myös toissijainen syy siihen, että sisällytin JSON-testauksen.
  • [Lisätty 1. syyskuuta päivitetyillä tuloksilla] Zewo on yksi kierresovellus. Voit saada siitä ylimääräistä suorituskykyä suorittamalla yhden sovelluksen esiintymän käytettävissä olevaa CPU: ta kohden, koska ne seuraavat samanaikaista eikä monisäikeistä mallia. Tämän tutkimuksen tarkoituksiin ajettiin vain yksi esimerkki jokaisesta sovelluksesta.
  • Työvälineenä. Jokainen kehys rakentaa erilaisen kehityksen tilannevedoksen työkaluketjun Applelta. Viimeisen testauksen aikaan he olivat / ovat:
     
    - KEHITYS-SNAPSHOT-2016-08–24-a täydelliselle
    - KEHITYS-SNAPSHOT-2016-07–25-a Vapor & Kituralle
    - KEHITYS-SNAPSHOT-2016-05–09-a Zewolle
  • Vaporilla on erityinen syntaksi julkaisujen ajamiseen. Jos suoritat vain binäärin, saat jonkin ylimääräisen konsolilokin, jonka on tarkoitus auttaa kehittämisessä ja virheenkorjauksessa. Siinä on vähän yläpuolella. Jotta Vapor toimisi vapautustilassa, sinun täytyy lisätä
--env = tuotanto

suoritettavalle. toisin sanoen.

.build / release / App --env = tuotanto
  • [Lisätty 1. syyskuuta päivitetyillä tuloksilla] Kun työskentelet Zewon kanssa, vaikka et pysty rakentamaan nopeaa julkaisutilassa 05–09-a-työkaluketjussa, voit lisätä joitain julkaisutilan optimointeja lähettämällä nämä argumentit:
nopea rakentaa -Xswiftc -O
  • Node.js / Express ei rakenna eikä tee eroa virheenkorjauksen / julkaisun välillä
  • Staattinen tiedostojen käsittely sisältyy Vaporin oletusväliohjelmaan. Jos et käytä staattisia tiedostoja ja haluat optimoida nopeuden, sinun on sisällytettävä (kuten tein VaporJSON: ssä):
drop.middleware = []

Miksi Node.js / Express?

Päätin sisällyttää blogin muunnelman Node.js: n Express-kehysten avulla. Tämä on hyvä vertailu, koska sillä on hyvin samanlainen syntaksi kuin Server-Side Swift ja sitä käytetään laajalti. Se auttaa luomaan hyvän perustason osoittaakseen kuinka vaikuttava Swift voi olla.

Blogien kehittäminen

Jossain vaiheessa aloin kutsua tätä ”jahtaavan palavan pallon”. Nykyisiä Server-Side Swift -kehyksiä kehitetään erittäin aktiivisesti, kuten Swift 3, ja jokaisessa on paljon muutoksia aikaisempiin versioihinsa. Tätä vahvisti kaikkien palvelinpuolen Swift-kehysten sekä Applen Swift-tiimin usein toistuvat julkaisut. Kukaan heistä ei ollut tässä vaiheessa erityisen täydellistä dokumentoinnissaan, joten olen erittäin kiitollinen puiteryhmien jäsenille ja koko Server-Side Swift -yhteisölle heidän panoksestaan. Olen myös kiitollinen avusta, jonka lukemattomat yhteisön jäsenet ja puiteryhmät antoivat minulle matkalla. Se oli hauskaa, ja tekisin sen uudelleen ajattelematta.

Sivuhuomautuksena, vaikka lisensointia ei edellytetty määrittelemistä, minusta on hienoa todeta, että kaikki lähteissä olevat satunnaiset rojaltittomat kuvat ovat Pixbayltä ja ne on valittu satunnaisesti. Tällaiset lähteet helpottavat demoprojekteja.

Hosting ja ympäristö

Ympäristön erojen minimoimiseksi otin 2012 Mac Mini -sovelluksen ja annoin sille puhtaan asennuksen El Capitanista (10.11.6). Sen jälkeen olen ladannut ja asentanut Xcode 8 beeta 6: n ja asentanut komentorivityökaluihini Xcode 8. Sieltä asensin swiftenv, asensin tarvittavat tilannevedokset, kloonin repot ja rakensin jokaisen blogin siististi, jälleen julkaisutilassa. mahdollista. En koskaan juoksi useampaa kuin yhtä kerrallaan, ja jokainen pysäytettiin ja käynnistettiin uudelleen testien välillä. Testipalvelimen tekniset tiedot ovat:

Kehitykseen käytän vuoden 2015 rMBP: tä. Vedin rakennusaikakokeita täällä, koska tämä on minun tosielämän kehityskonemani ja se oli eniten järkevää. Käytin wrk: tä vertailuarvojen saamiseksi ja tein tämän ukkosillan yli silloin, kun ukkospultti 2 -kaapeli oli koneiden välillä. Thunderbolt-sillan käyttö varmistaa, että sinulla on uskomattoman suuri kaistanleveys ja että et vertaile reitittimen rajoituksia kyseisen tehtävän sijaan. Luotettavampaa on myös palvella blogeja yhdellä koneella ja käyttää erillistä, tehokkaampaa laitetta kuorman luomiseen varmistaen, että pystyt ylikuormittamaan palvelinta niin, että voit olla varma, että tämä ei ole rajoitus. Tämä antaa sinulle myös yhdenmukaisen testausympäristön, joten voin sanoa, että jokainen blogi ajettiin samalla laitteistolla ja samoissa olosuhteissa. Kummallisia varten koneeni tekniset tiedot ovat:

Vertailuohjeet

Esikuva-analyysiin päätin käyttää kymmenen minuutin testiä, jossa on neljä säiettä, joissa molemmissa on 20 liitosta. Neljä sekuntia ei ole testi. Kymmenen minuuttia on kohtuullinen aikataulu saada paljon tietoa, ja 20 yhteyden suorittaminen neljällä ketjulla on blogien kova kuorma, mutta ei rikkova kuorma.

Lähdekoodi

Jos haluat tutustua projektien lähdekoodiin tai tehdä jonkin oman testauksen, yhdistin testauksessa käytetyn koodin yhteen arkistoon, joka löytyy osoitteesta:

https://github.com/rymcol/Server-Side-Swift-Benchmarking

Yksityiskohtaiset tulokset

Rakennusaika

Ajattelin, että olisi hauskaa ensin katsoa rakennusaikoja. Rakennusajalla voi olla suuri rooli päivittäisessä kehityksessä, ja vaikka sillä ei ole juurikaan tekemistä kehyksen esityksen kanssa, ajattelin, että voisi olla hauskaa tutkia todellisia lukuja vs. kuinka kauan asiat tuntuivat odottaessani.

Mitä ajettiin

Jokaisessa kehyksessä

nopea rakennus - puhdista = dist

ja sitten

aika nopeasti rakentaa

ajettiin, mitä seurasi toinen testi

nopea rakennus - puhdistaa

sitten:

aika nopeasti rakentaa

Tämä vaikuttaa sekä täyteen rakennukseen, joka sisältää riippuvuuksien vetämisen SPM: llä, että tavalliseen, puhtaan kokoonpanoon jo ladattujen riippuvuuksien kanssa.

Kuinka sitä käytettiin

Tätä ajettiin paikallisella 2015 rMBP: lläni ja kaikki rakennukset tehtiin debug-tilassa, koska tämä on normaali prosessi Swift-ohjelmistoa kehitettäessä.

Rakennusajan tulokset

Muistin käyttö

Toinen asia, jota tarkastelin, oli kunkin kuormitetun kehyksen muistijalanjälki.

Mikä oli Run

Ensimmäinen - aloitusmuistin jalanjälki (vain tuijotti prosessia)
2. - huippumuistin käyttö prosessissa testipalvelimellani käyttämällä:

wrk -d 1m -t 4 -c 10

3. - Toista toinen testi käyttäen:

wrk -d 1m -t 8 -c 100

Kuinka se oli Run

Tämä testi suoritettiin puhtaalla Mac minillä, joka oli tarkoitettu testipalvelimeksi. Jokainen kehys rakennettiin vapautustilaan mahdollisuuksien mukaan. Komentoriviltä ajettiin vain yksi kehys kerrallaan, ja se käynnistettiin uudelleen testien välillä. Ainoa toinen avoin ikkuna testauksen ajankohtana oli aktiivisuusmonitori, jota käytin visuaalisen muistin käytön visualisoimiseksi. Kun jokainen kehys ajettiin, huomasin vain korkeimman arvon, joka ilmestyi aktiviteettinäytön ikkunaan.

Muistin käytön tulokset

Langan käyttö

Kolmas asia, jota tarkastelin, oli kunkin kehyksen langan käyttö kuormitettuna.

Mikä oli Run

Ensimmäinen - aloituslangat (vain tuijotti prosessia)
2. - huippukierre Prosessin käyttö testipalvelimellani käyttämällä:

wrk -d 1m -t 4 -c 10

Kuinka se oli Run

Tämä testi suoritettiin puhtaalla Mac minillä, joka oli tarkoitettu testipalvelimeksi. Jokainen kehys rakennettiin vapautustilaan mahdollisuuksien mukaan (lisätietoja siitä metodologiaosiossa). Komentoriviltä ajettiin vain yksi kehys kerrallaan, ja se käynnistettiin uudelleen testien välillä. Ainoa toinen avoin ikkuna testauksen ajankohtana oli aktiivisuusmonitori, jota käytin visioimaan langan käyttöä. Kun jokainen kehys ajettiin, havaitsin yksinkertaisesti korkeimman arvon, joka ilmestyi aktiviteettinäyttöikkunaan testin ollessa käynnissä.

Huomautus tuloksista

Tässä kategoriassa ei ole "voittamista". Monet sovellukset käsittelevät lankoja eri tavalla, ja nämä puitteet eivät ole poikkeus. Esimerkiksi, Zewo on yksi kierresovellus, ja se ei koskaan käytä useampaa kuin yhtä (muokkaa: ilman sinun toimia, jotta ajaa sitä jokaisessa CPU: ssa samanaikaisessa kokoonpanossa). Toisaalta täydellinen käyttää yhtä käytettävissä olevaa prosessoria kohden. Höyry käyttää yhtä kytkentämallia kohden. Sellaisenaan tämä kaavio on suunniteltu siten, että kuormitettujen lankojen piikit ovat helposti nähtävissä, koska ne ovat samassa järjestyksessä molemmissa kuvaajissa.

Kielen käytön tulokset

Blogin vertailuarvot

Ensimmäinen vertailukohta on / blogin reitti jokaisessa, joka on sivu, joka palauttaa 5 satunnaista kuvaa ja vääriä blogi-viestejä jokaisesta pyynnöstä.

Mikä oli Run

wrk -d 10m -t 4 -c 20 http://169.254.237.101:(PORT)/blog

ajettiin jokaiselle blogelleni rMBP: stäni ukkosillan yli.

Kuinka se oli Run

Kuten muistitestauksessa, jokainen kehys ajettiin vapautustilassa mahdollisuuksien mukaan, ja se pysäytettiin ja käynnistettiin uudelleen ennen kutakin testiä. Vain yksi kehys oli käynnissä milloin tahansa palvelimella. Kaikista aktiivisuuksista tehtiin testien aikana vähimmäisvaatimukset ympäristön pitämiseksi mahdollisimman samanlaisena.

tulokset

Tämä kuva päivitettiin 1. syyskuuta 2016 korjauksellaTämä kuva päivitettiin 1. syyskuuta 2016 korjauksella

JSON-vertailuarvot

Joidenkin staattisten tiedostojen käsittelyyn liittyvien ongelmien vuoksi tuntui oikeudenmukaisemmalta suorittaa samat testit uudelleen yksinkertaisemman käyttöliittymän avulla, joten lisäsin kunkin sovelluksen versiot, jotka on hiekkalaatikossa / json-reitille, joka palauttaa kymmenen satunnaislukua 0: n sisällä. -1000. Ne ovat erillisiä varmistaakseen, että staattiset tiedostojen käsittelijät ja väliohjelmat eivät häiritse tuloksia.

Mikä oli Run

wrk -d 10m -t 4 -c 20 http://169.254.237.101:(PORT)/json

ajettiin jokaiselle JSON-projektille.

Kuinka se oli Run

Kuten muutkin testit, kukin kehys ajettiin vapautusmoodissa mahdollisuuksien mukaan, ja se pysäytettiin ja käynnistettiin uudelleen ennen kutakin testiä. Vain yksi kehys oli käynnissä milloin tahansa palvelimella. Kaikista aktiivisuuksista tehtiin testien aikana vähimmäisvaatimukset ympäristön pitämiseksi mahdollisimman samanlaisena.

tulokset

Tämä kuva päivitettiin 1. syyskuuta 2016 korjauksellaTämä kuva päivitettiin 1. syyskuuta 2016 korjauksella

johtopäätökset

Kysymykseeni vastattiin ylivoimaisella kyllä. Swift on enemmän kuin kykenevä ottamaan käyttöön vakiintuneet palvelinpuolen kehykset. Ei vain, mutta kaikki palvelinpuolen Swift-kehykset toimivat uskomattoman hyvin, ja ainakin kaksi heistä voitti Node.js: n jokaisessa testissä.

Koska palvelinpuolen Swift voi säästää hullua aikaa jakaa koodikantaansa muiden Swift-sovellusten, palvelinpuolen eri Swift -kehysten ominaisuusjoukkojen ja tässä olevien tulosten kanssa, sanoisin, että palvelinpuolen Swift toimii hyvin tapa olla erittäin iso haastaja ohjelmointialueella. Ohjelmoin henkilökohtaisesti niin paljon kuin mahdollista Swiftissä, etenkin palvelinpuolella, enkä voi odottaa nähdä kaikkia uskomattomia projekteja, jotka nousevat esiin yhteisöstä!

Ota mukaan

Jos olet kiinnostunut Server-Side Swiftistä, nyt on aika osallistua! Kehyksillä, niiden dokumentoinnilla on vielä paljon tehtävää ja todella hienon sovelluksen saaminen siellä esimerkkinä, avoin tai suljettu lähde. Voit oppia lisää jokaisesta kehyksestä ja osallistua täällä:

Täydellinen: verkkosivusto | Github | Löysä | gitter
Vapor: Verkkosivusto | Github | löysä
Kitura: Verkkosivusto | Github | gitter
Zewo: Verkkosivusto | Github | löysä

Ota yhteyttä

Jos haluat muodostaa yhteyden, voit tavoittaa minut @rymcol Twitterissä.

Pidän tarpeellisina ilmoituksia: Muokkauksia lisättiin 1. syyskuuta 2016 joidenkin tietojen korjaamiseksi sen jälkeen, kun julkaisuoptimoinnit tehtiin Zewolle käyttämällä vaihtoehtoista menetelmää "nopeaan build-c-julkaisuun". PerfectlySoft Inc. suostui rahoittamaan tätä tutkimusta minulle edistämään Swiftin voimaa. Olen myös Perfect & Vapor -ryhmän jäsenryhmissä, vaikka en ole kummankaan työntekijä, enkä heijasta mielipiteitäni. Olen tehnyt parhaani pysyäkseen puolueettomana kehittyessäni kaikilla neljällä alustalla ja olin todella utelias nähdä tulokset. Kaikki koodi on julkisesti saatavilla tälle tutkimukselle. Tarkista se tai toista joitain testejä ja varmista se itse!