Parima serveripoolse Swift-raamistiku ja Node.js võrdlusalused

Redigeerimine 7. oktoober: Checkout my Follow Up: Benchmarks for Linux (Ubuntu)

Sissejuhatus

Hiljuti töötasin server-Side Swiftis ja minult küsiti järgmist küsimust:

“Kas Server-Side Swift suudab võita Node.js?”

Swift kui kõige põhikeel kõigele, sealhulgas serverile, on olnud intrigeeriv alates sellest, kui see esmakordselt avati ja Linuxisse pandi. Paljud teist on kindlasti sama uudishimulikud kui mina, nii et mul on väga hea meel siin oma uuringu tulemusi jagada.

Parimad serveripoolsed Swift-raamistikud

Selle kirjutamise ajal on populaarsemad serveripoolsed Swift-raamistikud (GitHubis tähtede järjekorras):

  • Täiuslik ️7 956
  • Aur ️5,183
  • Kitura ️4,017
  • Zewo ️1 186

Selle postituse korraldus

See dokument on koostatud järgmiselt:

  • See kiire sissejuhatus
  • Tulemuste kokkuvõte
  • Metoodika
  • Üksikasjalikud tulemused
  • Järeldused ja lõplikud märkused

Tulemuste kokkuvõte

Järgnev on kiire kokkuvõte peamistest võrdlusnäitajatest ja ma ütlen seda siin:

Vaatamata üksikutele paremusjärjestustele, toimisid kõik need raamid uskumatult hästi, Swift peksis järjekindlalt Node.js-d ja nendega oli kõigil väga lõbus töötada.
Seda pilti värskendati 1. septembril 2016 parandusega

Metoodika ja märkused

Miks kasutada blogisid ja JSON-i?

Lihtsamalt öeldes on ajaveebid enam kui lihtsalt tere tagasi tulemine ja JSON on väga levinud kasutusjuhtum. Head võrdlusnäitajad vajavad iga raamistiku jaoks sarnast koormust ja see pidi olema natuke suurem koormus, mis prindib ekraanile kaks sõna.

Hoides asju sama

Üks peamisi teemasid, millest püüdsin kinni pidada, oli kõigi ajaveebide võimalikult sarnaste hoidmine, arendades samas iga raamistiku stiili ja süntaksit. Paljusid struktuure, nagu sisu genereerimist, korratakse kogu sõna-sõnalt, nii et igal raamistikul on ühesugused andmemudelid, millega töötada, kuid sellised tahud nagu URL-i marsruutimine on mõnikord täiesti erinevad, et need sobiksid iga raamistiku süntaksi ja stiiliga.

Peened erinevused

Serveripoolse kiire raamistiku vahel on mõned peened erinevused.

  • Nii Kitural kui ka Zewol on probleeme ehitamisega, kui nende absoluutses failiteedes on tühikuid. Xcode'il on probleeme ka tühikute loomisega absoluutsete failiteede korral mis tahes raamistikus.
  • Zewo kasutab pilti 05–09-a Swift, mis tähendab, et tal on raskusi vabastamisrežiimis ehitamisega ja seda tuleb käivitada silumisrežiimis. Kõik Zewo testid tehti sel põhjusel, kui Zewo oli ehitatud ja töötab silumisrežiimis (ilma väljalaske optimeerimiseta).
  • Staatiline failikäsitlus on serveripoolse Swift-raamistiku hulgas arutelupunkt. Nii Vapor kui ka Zewo soovitavad staatiliste failide käsitlemisel puhverserverina kasutada Nginxit, pannes raamistiku tagapõhja töötlemisvõimena taha. Perfect soovitab kasutada nende sisseehitatud käitlejat ja ma ei ole IBM-i kohta kommentaare nende enda selleteemaliste vaadete kohta. Kuna see uuring ei puudutanud seda, kui hästi raamistikud töötavad väljakujunenud serverirakendustega nagu Nginx, kasutati staatilist failihaldust loomulikult iga raamistiku puhul. Võib-olla on teil võimalik saavutada parem jõudlus nii Vaporis kui ka Zewos, kui otsustate seda silmas pidades ehitada. See on ka teisejärguline põhjus, miks ma lisasin JSON-testimise.
  • [Lisatud 1. september värskendatud tulemustega] Zewo on ühe keermega rakendus. Lisateavet saate sellest, kui käivitate ühe rakenduse eksemplari iga saadaoleva CPU kohta, kuna need järgivad samaaegset, mitte mitme keermega mudelit. Selle uuringu jaoks käivitati igast rakendusest ainult üks eksemplar.
  • Tööriistad. Iga raamistik loob Apple'ilt erineva arengupiltide tööriistaketi. Lõpliku testimise ajal olid / on:   - ARENG-SNAPSHOT-2016-08–24-a täiuslikuks - ARENG-SNAPSHOT-2016-07–25-a ettevõttele Vapor & Kitura - ARENG-SNAPSHOT-2016-05–09-a Zewo jaoks
  • Vaporil on väljalaske käitamiseks spetsiaalne süntaks. Kui te lihtsalt täidate kahendkoodi, saate mõne täiendava konsoolilogimise, mis on mõeldud arengu- ja silumisprotsessi abistamiseks. Sellel on natuke üle pea. Vapori käivitamiseks vabastamisrežiimis peate lisama
--env = tootmine

käivitatavale. s.t.

.build / release / App --env = tootmine
  • [Lisatud 1. september koos värskendatud tulemustega] Kui töötate Zewoga, isegi kui te ei saa tööriistaribal 05–09-a vabastamisrežiimis kiiret ehitada, saate lisada mõned vabastamisrežiimi optimeerimised, edastades need argumendid:
kiire ehitamine -Xswiftc -O
  • Node.js / Express ei ehita ega erista silumist / vabastamist
  • Staatiline failihaldus on kaasatud Vapoori vaiketarkvara. Kui te ei kasuta staatilisi faile ja soovite kiirust optimeerida, peate lisama (nagu ma tegin VaporJSON-is):
drop.middleware = []

Miks Node.js / Express?

Otsustasin lisada blogi variatsiooni, kasutades Node.js Expressi raamistikku. See on hea võrdlus, kuna sellel on Server-Side Swiftiga väga sarnane süntaks ja seda kasutatakse laialdaselt. See aitab luua hea lähtejoone, et näidata, kui muljetavaldav Swift võib olla.

Blogide arendamine

Mingil hetkel hakkasin seda nimetama “kopsaka palli tagaajamiseks”. Praegused serveripoolsed Swifti raamistikud, nagu ka Swift 3, on väga aktiivse arendamise all ja kõigil neist on palju muudatusi oma eelmistest versioonidest. Seda võimendasid kõigi serveripoolsete Swifti raamistike, samuti Apple'i Swifti meeskonna sagedased väljaanded. Ükski neist polnud sel hetkel oma dokumentide osas eriti täielik, seetõttu olen südamest tänulik raammeeskondade liikmetele ja laiemalt Server-Side Swifti kogukonnale nende panuse eest. Olen ka tänulik abi eest, mida lugematud kogukonna liikmed ja raammeeskonnad mulle selle tee ääres andsid. See oli palju nalja ja ma teeksin seda uuesti, mõtlemata.

Kõrvaliseks märkuseks, et kuigi omistamist litsents ei nõudnud, on mul siiski tore tõdeda, et kõik allikates sisalduvad juhusliku kasutustasuta pildid on pärit Pixbayst ja need valisin minu poolt juhuslikult. Sellised allikad muudavad demoprojektid palju lihtsamaks.

Vastuvõtt ja keskkond

Keskkonna erinevuste minimeerimiseks võtsin kasutusele 2012. aasta Mac Mini ja andsin sellele El Capitani puhta versiooni (10.11.6). Pärast seda laadisin alla ja installisin Xcode 8 beeta 6 ning seadsin oma käsureatööriistade väärtuseks Xcode 8. Sealt installisin swiftenvi, installisin vajalikud hetktõmmised, kloonisin reposid ja ehitasin kõik ajaveebid uuesti, uuesti väljalaskerežiimis, kus võimalik. Ma ei jooksnud kunagi rohkem kui ühte korraga ja igaüks peatati ja taaskäivitati katsete vahel. Testiserveri andmed on järgmised:

Arenduseks kasutan 2015. aasta rMBP-d. Käisin siin ehituse ajateste, kuna see on minu tegeliku elu arendamise masin ja see oli kõige mõistlikum. Võrdlusaluste saamiseks kasutasin wrk-i ja tegin selle üle okkpoldi silla, kasutades masinate vahelist thunderbolt 2 kaablit. Piksesilla kasutamine võimaldab veenduda, et teil on uskumatult palju ribalaiust ja et te ei võrdle oma ülesande asemel ruuteri piiranguid. Usaldusväärsem on ka ajaveebide teenindamine ühes masinas ja koormuse genereerimiseks eraldi, võimsama masina kasutamine, tagades, et suudate serverit üle koormata, nii et võite olla kindel, et see pole piirang. See annab teile ühtlase testimiskeskkonna, nii et võin öelda, et iga ajaveebi käitati sama riistvara ja samades tingimustes. Uudishimulikele on minu masina tehnilised andmed järgmised:

Võrdlusuuringute märkused

Võrdlusuuringuteks otsustasin kasutada kümne minuti pikkust nelja niidiga testi, millest igaüks sisaldas 20 ühendust. Neli sekundit pole test. Kümme minutit on mõistlik ajakava, et saada palju andmeid, ja 20 ühenduse loomine neljal lõimel on ajaveebide jaoks kopsakas koormus, kuid mitte purunev koormus.

Lähtekood

Kui soovite uurida projektide lähtekoodi või teha mõnda oma testimist, ühendasin testimiseks kasutatud koodi ühte hoidlasse, mille leiate aadressilt:

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

Üksikasjalikud tulemused

Ehitamise aeg

Arvasin, et kõigepealt oleks lõbus vaadata ehituse aegu. Ehituse aeg võib mängida olulist rolli igapäevases arengus ja kuigi sellel on vähe pistmist raamistiku etendusega, arvasin, et võib olla lõbus uurida reaalseid numbreid ja seda, kui kaua asjad ootasid.

Mida juhiti

Iga raamistiku jaoks

kiire ehitamine - puhastamine = dist

ja siis

kiire ehitamine

sõideti, millele järgnes teine ​​test

kiire ehitamine - puhastamine

siis:

kiire ehitamine

See tingib nii täieliku ehituse, sealhulgas sõltuvuste tõmbamise SPM-iga, kui ka tavalise puhta ehituse juba allalaetud sõltuvustega.

Kuidas seda juhiti

Seda juhiti minu kohalikul 2015 rMBP-l ja kõik ehitamised tehti silumisrežiimis, kuna see on Swifti tarkvara väljatöötamisel tavaline protsess.

Koostamise tulemused

Mälu kasutamine

Teine asi, mida ma vaatasin, oli iga koormatud raami mälujälg.

Mis oli Run

Esimene - mälumahu alustamine (lihtsalt vaatas protsessi)
2. - mälupiirkonna protsess Protsessi kasutamine minu testiserveris, kasutades:

wrk -d 1m -t 4 -c 10

3. - teise katse kordus, kasutades:

wrk -d 1m -t 8 -c 100

Kuidas see jooksis

Seda testi tehti puhtas Mac minis, mis oli ette nähtud katseserveriks. Iga raamistik ehitati võimaluse korral väljalaskerežiimis. Korraga käivitati käsurealt ainult üks raamistik ja see käivitati testide vahel uuesti. Ainus testimise ajal avatud aken oli aktiivsusmonitor, mida kasutasin mälu maksimaalse kasutamise visualiseerimiseks. Iga raamistiku käivitamisel märkisin lihtsalt kõrgeima väärtuse, mis ilmnes aktiivsusmonitori aknas.

Mälukasutuse tulemused

Keerme kasutamine

Kolmas asi, mida ma vaatasin, oli iga raamistiku niidikasutus koormatud tingimustes.

Mis oli Run

1. - algusniidid (lihtsalt vahtinud protsessi)
2. - tippniit Protsessi kasutamine minu testiserveris, kasutades:

wrk -d 1m -t 4 -c 10

Kuidas see jooksis

Seda testi tehti puhtas Mac minis, mis oli ette nähtud katseserveriks. Iga raamistik ehitati võimaluse korral väljalaskerežiimis (lähemalt sellest, mis on toodud metoodika jaotises). Korraga käivitati käsurealt ainult üks raamistik ja see käivitati testide vahel uuesti. Ainus testimise ajal avatud aken oli aktiivsusmonitor, mida kasutasin niidi kasutamise visualiseerimiseks. Iga raamistiku käivitamisel märkisin lihtsalt suurima väärtuse, mis testimise ajal aktiivsusmonitori aknas ilmnes.

Märkus nende tulemuste kohta

Selles kategoorias pole ühtegi võitjat. Paljud rakendused käsitlevad lõime erinevalt ja need raamistikud pole erandiks. Näiteks on Zewo ühe keermega rakendus ja see ei kasuta kunagi rohkem kui ühte (redigeerimine: ilma teie sekkumiseta, et käivitada see igal protsessoril samaaegses konfiguratsioonis). Täiuslik seevastu kasutab ühte saadaoleva keskseadme kohta. Aur kasutab ühte ühendusmudelit. Sellisena oli see graaf kavandatud nii, et koormuse all olevate keermete naelu oleks hõlpsasti näha, kuna need asuvad mõlemal graafikul samas järjekorras.

Keerme kasutamise tulemused

Blogi võrdlusnäitajad

Esimene võrdlusalus on igas blogis / marsruut, mis on leht, mis tagastab iga päringu kohta 5 juhuslikku pilti ja võlts blogi postitust.

Mis oli Run

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

käivitati iga ajaveebi jaoks minu rMBP-st üle minu äikesesilla.

Kuidas see jooksis

Nagu mälu testimisel, töötati iga raamistik võimaluse korral vabastamisrežiimis ning enne iga testi peatati ja taaskäivitati. Korraga töötas serveris ainult üks raamistik. Kogu tegevus tehti katsetamise ajal mõlemas masinas minimaalseks, et keskkond püsiks võimalikult sarnane.

Tulemused

Seda pilti värskendati 1. septembril 2016 parandusegaSeda pilti värskendati 1. septembril 2016 parandusega

JSONi võrdlusalused

Kuna kõigil on staatiliste failide käsitlemise osas keeruline, tundus õiglasem samade testide uuesti käivitamine lihtsama liidese abil, nii et lisasin iga rakenduse versioonid, mis on liivakasti kantud a / json marsruudile, mis tagastab kümme juhuslikku arvu 0 piires. –1000. Need on eraldi veendumaks, et staatilised failide töötlejad ja vahevara ei sega tulemusi.

Mis oli Run

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

käivitati iga JSON-projekti jaoks.

Kuidas see jooksis

Nagu teiste testide puhul, töötati iga raamistik võimaluse korral vabastamisrežiimis ning enne iga testi peatati ja taaskäivitati. Korraga töötas serveris ainult üks raamistik. Kogu tegevus tehti katsetamise ajal mõlemas masinas minimaalseks, et keskkond püsiks võimalikult sarnane.

Tulemused

Seda pilti värskendati 1. septembril 2016 parandusegaSeda pilti värskendati 1. septembril 2016 parandusega

Järeldused

Minu küsimusele vastati ülekaalukalt JAH. Swift on enam kui võimeline võtma kasutusele väljakujunenud serveripoolsed raamistikud. Mitte ainult, vaid ka kõik serveripoolsed SWIFT-raamistikud toimisid uskumatult hästi ja Node.js-i peksis neist vähemalt kaks testi.

Kuna serveripoolne Swift võib kokku hoida hullu aega, jagades oma andmebaasi oma teiste Swifti rakendustega, erinevate serveripoolsete Swifti raamistike funktsioonikomplektidega ja siin toodud tulemustega, võiksin öelda, et serveripoolne Swift on hästi viis olla väga suur kandidaat programmeerimise areenil. Ma programmeerin isiklikult nii palju kui võimalik Swiftis, eriti serveripoolel, ja ma ei saa oodata, millal ma näen kõiki uskumatuid projekte, mis kogukonnast välja tulevad!

Osalege

Kui olete huvitatud server-Side Swiftist, siis nüüd on aeg sellega tegeleda! Raamide, nende dokumenteerimise ja veel väga lahedate rakenduste hankimise näitena, avatud või suletud allikana on vaja veel palju ära teha. Iga raamistiku kohta saate lisateavet ja seal osaleda:

Täiuslik: veebisait | Github | Lõtv | Gitter
Vapor: Veebisait | Github | Lõtv
Kitura: Veebisait | Github | Gitter
Zewo: Veebisait | Github | Lõtv

Ühendust võtma

Kui soovite ühenduse luua, võite minu poole pöörduda @rymcol Twitteris.

Avalikustamine, mida ma pidasin vajalikuks: muudatused lisati 1. septembriks 2016, et parandada mõningaid andmeid pärast seda, kui Zewo jaoks oli väljalaske optimeerimine tehtud, kasutades alternatiivset meetodit kiirele ehitamisele -c vabastamisele. PerfectlySoft Inc. nõustus minu jaoks seda uuringut rahastama, et edendada Swifti jõudu. Olen ka Perfect & Vapor gruppide meeskonnas, ehkki ma ei ole kummagi töötaja ja minu arvamused ei kajasta minu arvamust. Olen andnud endast parima, et jääda erapooletuks, arenedes kõigil neljal platvormil ja mul oli siiralt uudishimu tulemusi näha. Kogu kood on selle uuringu jaoks avalikult saadaval. Vaadake seda julgelt läbi või korrake mõnda testi ja kontrollige seda ise!