Viðmið fyrir helstu Swift ramma netþjóna á móti Node.js

Breyta 7. október: Athugaðu eftirfylgni mína: Viðmið fyrir Linux (Ubuntu)

Kynning

Nýlega var ég að vinna í Server-Side Swift og ég var spurð spurningarinnar:

„Getur Swift frá netþjóni slegið Node.js?“

Snöggt sem aðal tungumál fyrir allt, þar á meðal netþjóninn, hefur verið forvitnilegt síðan það var fyrst opnað og flutt í Linux. Mörg ykkar eru vissulega eins forvitin og ég, svo ég er mjög ánægður með að deila niðurstöðum rannsóknarinnar hér.

The toppur Swift ramma netþjóna

Þegar þetta er skrifað eru helstu Swift Framew Server-Side (skráð í röð stjarna á GitHub):

  • Fullkomið ,97.956
  • Gufa ️5.183
  • Kitura ️4,017
  • Zewo ️1,186

Skipulag þessa pósts

Þetta skjal er sett fram á eftirfarandi hátt:

  • Þessi snögga kynning
  • Niðurstöður niðurstaðna
  • Aðferðafræði
  • Nákvæmar niðurstöður
  • Niðurstaða og lokaskýringar

Niðurstöður niðurstaðna

Eftirfarandi er fljótt yfirlit yfir helstu viðmið og ég mun segja þetta hér:

Sama hver einstaklingur var í röðinni, öll þessi ramma stóðu sig ótrúlega vel, Swift sló stöðugt Node.js og voru þeir allir mjög skemmtilegir að vinna með.
Þessi mynd var uppfærð 1. september 2016 með leiðréttingu

Aðferðafræði og skýringar

Af hverju að nota blogg og JSON?

Einfaldlega eru blogg meira en að skila „Halló, heimur!“ Og JSON er mjög algengt mál. Góð viðmið þurfa svipað álag á hvern ramma og það þurfti að vera aðeins meira álag til að prenta tvö orð á skjáinn.

Að halda hlutunum eins

Eitt helsta þemað sem ég reyndi að halda fast við var að halda öllum bloggunum eins líkum hvort öðru og mögulegt var, en var samt að þróa í stíl og setningafræði hvers ramma. Margar uppbyggingar, eins og kynslóð efnis, eru endurteknar í orðréttri röð, þannig að hver rammi hefur sömu gagnalíkön til að vinna með, en hliðar eins og vefleiðbeiningar eru stundum mjög ólíkar til að passa við setningafræði og stíl hvers ramma.

Fínlegur munur

Það er nokkur lúmskur munur sem þarf að hafa í huga milli Swift Frameworks Server-Side.

  • Bæði Kitura og Zewo eiga í vandræðum með að byggja upp ef það eru einhver rými í algerum skráarslóðum þeirra. Xcode hefur einnig vandamál með byggingu með rými í algerum skráarslóðum í hvaða ramma sem er.
  • Zewo er að nota 05–09-a Swift myndatöku, sem þýðir að hann á í vandræðum með að byggja upp í losunarstillingu og þarf að keyra í kembiforriti. Öll Zewo próf voru framkvæmd með Zewo byggð og keyrt í kembiforriti (án hagsbótaútgáfu) af þessum sökum.
  • Stöðug skjöl meðhöndlun er umræðuatriði meðal Swift Framew Server-Side. Vapor og Zewo mæla báðir með því að nota Nginx sem umboð fyrir kyrrstæða skráarafgreiðslu og setja síðan umgjörðina að baki því sem vinnsluafl fyrir stuðninginn. Perfect bendir til þess að nota innbyggða stjórnandann sinn og ég hef ekki séð neinar athugasemdir við IBM varðandi skoðanir þeirra á málinu. Þar sem þessi rannsókn snerist ekki um hversu vel rammar virka með þekktum netþjónaforritum eins og Nginx, var truflun meðhöndlun notuð innan hvers ramma. Þú gætir verið að ná betri árangri í bæði Vapor og Zewo ef þú velur að byggja með þetta í huga. Þetta er líka aukaástæðan fyrir því að ég tók JSON próf.
  • [Bætt við 1. september með uppfærðum árangri] Zewo er forrit með einum snittum. Þú getur fengið aukna afköst af því með því að keyra eitt dæmi af forritinu fyrir hvern CPU sem er í boði, þar sem þeir fylgja samhliða, frekar en fjölþráðum líkani. Að því er varðar þessa rannsókn var aðeins keyrt eitt dæmi af hverju forriti.
  • Verkfæraskúr. Hver rammi er að byggja upp annan tækjabúnað fyrir snapshot frá Apple. Þegar lokapróf voru / voru þau:
     
    - ÞRÓUN-SNAPSHOT-2016-08–24-a fyrir fullkomið
    - ÞRÓUN-SNAPSHOT-2016-07–25-a fyrir Vapor & Kitura
    - ÞRÓUN-SNAPSHOT-2016-05–09-a fyrir Zewo
  • Vapor hefur sérstaka setningafræði til að keyra útgáfur. Ef þú keyrir einfaldlega tvöfaldan muntu fá smá auka hugga skógarhögg sem er ætlað að hjálpa við þróun og kembiforrit. Það hefur svolítið kostnað. Til að keyra Vapor í losunarstillingu þarftu að bæta við
--env = framleiðsla

við keyrsluna. þ.e.a.s.

.byggja / gefa út / App - env ​​= framleiðslu
  • [Bætt við 1. september með uppfærðum árangri] Þegar þú vinnur með Zewo, jafnvel þó að þú getir ekki smíðað með snöggu í losunarham á 05–09-verkfæraskúrinu, geturðu bætt við nokkrum hagræðingum á losunarstillingu með því að fara með þessi rök:
snögg byggja -Xswiftc -O
  • Node.js / Express byggir hvorki á milli né villur / losar
  • Stöðug skjöl meðhöndlun er innifalin í sjálfgefnu millitæki Vapor. Ef þú ert ekki að nota truflanir skrár og vilt fínstilla fyrir hraðann, verður þú að hafa (eins og ég gerði í VaporJSON):
drop.middleware = []

Af hverju Node.js / Express?

Ég ákvað að taka afbrigði af blogginu með því að nota Express ramma í Node.js. Þetta er góður samanburður vegna þess að hann hefur mjög svipaða setningafræði og Server-Side Swift og er mikið notaður. Það hjálpar til við að koma á góðum grunnlínu til að sýna hversu áhrifamikill Swift getur verið.

Að þróa bloggin

Á einhverjum tímapunkti byrjaði ég að kalla þetta „elta skoppandi boltann“. Núverandi Server-Side Swift ramma er í mjög virkri þróun, eins og Swift 3, og hefur hvert tonn af breytingum frá fyrri útgáfum. Þetta magnaðist með tíðum útgáfum frá öllum Server-Side Swift Frameworks, sem og Swift liðinu hjá Apple. Enginn þeirra var sérstaklega fullkominn í skjölum sínum á þessum tímapunkti, svo ég er mjög þakklátur meðlimum rammahópanna og Server-Side Swift samfélagsins í heild sinni fyrir framlag þeirra. Ég er líka þakklátur fyrir þá hjálp sem óteljandi samfélagsmeðlimir og rammateymi veittu mér á leiðinni. Þetta var tonn af skemmtun og ég myndi gera það aftur án þess að hugsa.

Sem hliðarathugun, þrátt fyrir að ekki hafi verið krafist eignaheimildar af leyfinu, þá finnst mér gaman að taka fram að allar handahófslausu kóngafólk sem er laus við kóngafólk er frá Pixbay og voru valdar af mér af handahófi. Heimildir sem þessar gera kynningarverkefni mun auðveldara.

Hýsing og umhverfi

Til að lágmarka mun á umhverfinu tók ég Mac Mini 2012 og gaf honum hreina uppsetningu af El Capitan (10.11.6). Eftir það sótti ég og setti upp Xcode 8 beta 6 og stillti skipanalínutækin mín á Xcode 8. Þaðan setti ég upp swiftenv, setti upp nauðsynlegar skyndimyndir, klónaði endurhverfurnar og smíðaði hreint hvert blogg, aftur í útgáfuham þar sem mögulegt. Ég hljóp aldrei fleiri en einn í einu og hver var stöðvaður og endurræstur á milli prófa. Sérstakar prófanir netþjónanna eru:

Til þróunar nota ég 2015 rMBP. Ég rak byggingartímaprófin hér, þar sem þetta er raunveruleg þróunarvélin mín og það var skynsamlegast. Ég notaði wrk til að ná viðmiðunum, og ég gerði þetta yfir þrumufleygbrú með þrumufleyg 2 snúru milli véla. Notkun þrumufleygsbrúar tryggir að þú hafir ótrúlega mikið af bandbreidd og að þú sért ekki að mæla saman takmarkanir leiðarinnar í stað verkefnisins. Það er líka áreiðanlegra að þjóna bloggunum á einni vél og nota sérstaka og öflugri vél til að búa til álagið og tryggja að þú sért fær um að yfirbuga netþjóninn svo þú getir verið viss um að þetta er ekki takmörkun. Þetta gefur þér líka stöðugt prófunarumhverfi, svo ég get sagt að hvert blogg var keyrt á sama vélbúnaði og við sömu aðstæður. Fyrir forvitinn, sérstakur af vélinni minni eru:

Kvóti viðmiða

Fyrir verðsamanburð ákvað ég að nota tíu mínútna próf með fjórum þræði sem báðir voru með 20 tengingar. Fjórar sekúndur eru ekki próf. Tíu mínútur eru hæfilegur tímarammi til að fá nóg af gögnum og það að reka 20 tengingar á fjórum þræði er álag fyrir bloggin en ekki brotleg álag.

Upprunakóði

Ef þig langar til að kanna frumkóðann fyrir verkefnin eða gera eitthvað af eigin prófunum, sameinaði ég kóðann sem notaður var til að prófa í eina geymslu sem er að finna á:

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

Nákvæmar niðurstöður

Byggja tíma

Ég hélt að það væri gaman að skoða fyrst byggingartíma. Uppbyggingartími getur spilað stórt hlutverk í þróun dagsins í dag og þó að það hafi lítið að gera með frammistöðu ramma, þá hélt ég að það gæti verið skemmtilegt að kanna rauntölur samanborið við hversu lengi hlutirnir voru meðan ég beið.

Hvað var rekið

Fyrir hvern ramma,

snöggur byggja - hreinn = dist

og svo

tíma skjótt byggja

voru keyrð, fylgt eftir með annarri prófun á

skjótt byggja - hreint

Þá:

tíma skjótt byggja

Þessir þættir eru bæði full bygging, þ.mt að treysta ósjálfstæði með SPM, sem og reglulega, hreina byggingu með nú þegar háð.

Hvernig það var rekið

Þetta var keyrt á staðbundnum 2015 rMBP mínum og smíðin voru öll gerð í kembiforriti, því þetta er eðlilegt ferli þegar ég þróa Swift hugbúnað.

Byggja tíma niðurstöður

Minni notkun

Annað sem ég leit á var minni fótspor hvers ramma undir álagi.

Hvað var hlaupið

1. - að byrja minnis fótspor (starði bara ferlinu)
2. - Peak Memory Notkun ferlisins á prufuþjóninum mínum með því að nota:

wrk -d 1m -t 4 -c 10

3. - Endurtekning á seinni prófinu með:

wrk -d 1m -t 8 -c 100

Hvernig það var hlaupið

Þetta próf var keyrt á hreinum Mac mini sem var tileinkaður prufuþjónn. Hver rammi var smíðaður í losunarstillingu þar sem hægt var. Aðeins einn rammi var keyrður frá skipanalínunni í einu og hann var endurræstur á milli prófa. Eini annar opni glugginn við prófunina var virkni skjár, sem var notaður af mér til að gera sjónminningu hámarksnotkunar. Þegar hver rammi var keyrður tók ég einfaldlega fram hæsta gildi sem birtist í glugganum fyrir aðgerðir eftirlitsins.

Niðurstöður minnisnotkunar

Notkun þráða

Það þriðja sem ég leit á var þráðarnotkun hvers ramma undir álagi.

Hvað var hlaupið

1. - byrjunarþræðir (starði bara ferlið)
2. - Peak Thread Notkun á ferlinu á prufuþjóninum mínum með því að nota:

wrk -d 1m -t 4 -c 10

Hvernig það var hlaupið

Þetta próf var keyrt á hreinum Mac mini sem var tileinkaður prufuþjónn. Hver rammi var smíðaður í útgáfuham þar sem hægt er (meira um það er í aðferðafræðihlutanum). Aðeins einn rammi var keyrður frá skipanalínunni í einu og hann var endurræstur á milli prófa. Eini annar opni glugginn á þeim tíma sem prófunin var virkni skjár, sem var notaður af mér til að sjón þráður notkun. Þegar hver rammi var keyrður tók ég einfaldlega fram hæsta gildi sem birtist í glugganum fyrir aðgerðaskjár meðan prófið var í gangi.

Athugasemd um þessar niðurstöður

Það er enginn „vinnandi“ í þessum flokki. Mörg forrit meðhöndla þræði á annan hátt og þessi ramma er engin undantekning. Til dæmis er Zewo eitt snittara forrit og það mun aldrei nota fleiri en eitt (breyta: án þíns afskipta til að keyra það á hverjum CPU í samtímis stillingu). Perfect, á hinn bóginn, mun nota einn á hverja lausa CPU. Gufu mun nota eitt fyrir hver tengslíkan. Sem slíkt var þetta línurit hannað þannig að topparnir í þræði undir álagi eru auðveldlega sýnilegir, þar sem þeir eru í sömu röð í báðum myndritunum.

Niðurstöður þráðanotkunar

Blog Viðmið

Fyrsta viðmiðið er / bloggleiðin í hverri, sem er síða sem skilar 5 handahófskenndum myndum og fölsuðum bloggfærslum fyrir hverja beiðni.

Hvað var hlaupið

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

var keyrt fyrir hvert blogg frá rMBP mínum yfir þrumufleygbrúnni minni.

Hvernig það var hlaupið

Eins og með minniprófunina, var hver rammi keyrður í losunarstillingu þar sem unnt var og var stöðvaður og endurræstur fyrir hvert próf. Aðeins einn rammi var í gangi á hverjum tíma á þjóninum. Öll virkni var lágmörk á báðum vélunum við prófunina til að halda umhverfinu eins svipuðu og mögulegt er.

Úrslit

Þessi mynd var uppfærð 1. september 2016 með leiðréttinguÞessi mynd var uppfærð 1. september 2016 með leiðréttingu

JSON viðmið

Vegna nokkurra fylgikvilla um það hvernig allir höndla kyrrstæður skrár fannst mér sanngjarnt að keyra sömu prófin aftur með einfaldara viðmóti, svo ég bætti við útgáfum af hverju forriti sem eru sandkassar á a / json leið sem skilar tíu handahófskenndum tölum innan 0 –1000. Þeir eru aðskildir til að ganga úr skugga um að truflanir skráarafgreiðslumanna og millitæki trufla ekki niðurstöðurnar.

Hvað var hlaupið

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

var keyrt fyrir hvert JSON verkefni.

Hvernig það var hlaupið

Eins og með önnur próf var hver umgjörð keyrð í losunarstillingu þar sem unnt var og var stöðvuð og endurræst á ný fyrir hvert próf. Aðeins einn rammi var í gangi á hverjum tíma á þjóninum. Öll virkni var lágmörk á báðum vélunum við prófunina til að halda umhverfinu eins svipuðu og mögulegt er.

Úrslit

Þessi mynd var uppfærð 1. september 2016 með leiðréttinguÞessi mynd var uppfærð 1. september 2016 með leiðréttingu

Ályktanir

Spurningu minni var svarað með yfirgnæfandi JÁ. Swift er meira en fær um að taka við rótum netþjóna. Ekki nóg með það, heldur gengu öll Server-Side Swift Framew ótrúlega vel og Node.js var barinn af að minnsta kosti tveimur þeirra í hverju prófi.

Í ljósi þess að Server-Side Swift getur sparað geðveikan tíma í að deila codebase með öðrum Swift forritunum þínum, eiginleikasætunum í hinum ýmsu Server-Side Swift ramma og niðurstöðurnar hérna myndi ég segja að Server-Side Swift er vel á því leið til að vera mjög stór keppinautur á forritunarvettvangi. Ég er persónulega að forrita eins mikið og mögulegt er í Swift, sérstaklega á netþjóninum, og ég get ekki beðið eftir að sjá öll ótrúlegu verkefnin sem koma upp úr samfélaginu!

Taka þátt

Ef þú hefur áhuga á Swift Server-Side er nú kominn tími til að taka þátt! Enn er mikil vinna að vinna í umgjörðunum, skjölum þeirra og að fá virkilega flott forrit þarna úti sem dæmi, opið eða lokað. Þú getur lært meira um hvern ramma og tekið þátt hér:

Fullkomið: Vefsíða | Github | Slaka | Gitter
Gufa: Vefsíða | Github | Slaki
Kitura: Vefsíða | Github | Gitter
Zewo: Vefsíða | Github | Slaki

Komast í samband

Ef þú vilt tengjast geturðu náð til mín @rymcol á Twitter.

Upplýsingum sem mér fannst nauðsynlegar: Breytingum var bætt við 1. september 2016 til að leiðrétta nokkur gögn eftir að hagræðing var gefin út fyrir Zewo með því að nota aðferð til að „skjótt byggja -c losun“. PerfectlySoft Inc. samþykkti að fjármagna þessa rannsókn fyrir mig, til að stuðla að krafti Swift. Ég er líka í github teymunum fyrir Perfect & Vapor, þó að ég sé ekki starfsmaður hvorki né endurspegla skoðanir mínar þeirra. Ég hef gert mitt besta til að vera hlutlaus, þegar ég þróast á öllum fjórum kerfum, og ég var virkilega forvitinn að sjá árangurinn. Allur kóðinn er aðgengilegur fyrir þessa rannsókn. Vinsamlegast ekki hika við það eða endurtaka prófin og sannreyna það sjálf!