Salīdzinošie rādītāji servera puses Swift ietvariem salīdzinājumā ar Node.js

7. oktobra rediģēšana: Izrakstīšanās manā darbībā: Linux etaloni (Ubuntu)

Ievads

Nesen es strādāju server-Side Swift, un man uzdeva jautājumu:

“Vai Server-Side Swift var pārspēt Node.js?”

Swift kā galvenā valoda visam, ieskaitot serveri, ir bijusi intriģējoša kopš brīža, kad tā pirmo reizi tika atvērta avotā un tika pārnesta uz Linux. Daudzi no jums, protams, ir tikpat ziņkārīgi kā es, tāpēc es esmu ļoti priecīgs dalīties šeit ar mana pētījuma rezultātiem.

Populārākie ātrie servera puses ietvari

Rakstīšanas laikā galvenie servera puses ātrie ietvari (sakārtoti GitHub zvaigznīšu secībā) ir:

  • Lieliski ️7,956
  • Tvaiki ️5,183
  • Kitura ️4,017
  • Zewo ️1,186

Šī amata organizācija

Šis dokuments ir sagatavots šādā veidā:

  • Šis ātrais ievads
  • Rezultātu kopsavilkums
  • Metodika
  • Detalizēti rezultāti
  • Secinājumi un nobeiguma piezīmes

Rezultātu kopsavilkums

Šis ir īss galveno etalonu kopsavilkums, un to es teikšu šeit:

Neatkarīgi no individuālā klasifikācijas, visi šie ietvari darbojās neticami labi, Swift konsekventi pārspēja Node.js, un ar viņiem visiem bija daudz prieka strādāt.
Šis attēls tika atjaunināts 2016. gada 1. septembrī ar labojumu

Metodika un piezīmes

Kāpēc izmantot emuārus un JSON?

Vienkāršāk sakot, emuāri ir kas vairāk nekā “Sveika, pasaule!” Atgriešanās, un JSON ir ļoti izplatīts lietošanas gadījums. Labiem etaloniem ir nepieciešama līdzīga slodze uz katru ietvaru, un tam bija jābūt nedaudz lielākam, drukājot divus vārdus uz ekrāna.

Turot lietas nemainīgas

Viena no galvenajām tēmām, kurai es centos pieturēties, bija visu emuāru turēšana pēc iespējas līdzīgākiem, vienlaikus attīstoties katra ietvara stilā un sintaksē. Daudzi no struktūrām, piemēram, satura ģenerēšana, tiek atkārtoti visu vārdu krājumu, tā ka katram ietvaram ir vienādi datu modeļi, ar kuriem strādāt, bet tādi aspekti kā URL maršrutēšana dažreiz ir krasi atšķirīgi, lai atbilstu katra ietvara sintaksei un stilam.

Smalkas atšķirības

Starp servera puses ātrajiem ietvariem ir jāņem vērā dažas smalkas atšķirības.

  • Gan Kitura, gan Zewo rada problēmas, ja to absolūtajos ceļu ceļos ir atstarpes. Xcode ir problēmas arī ar atstarpju veidošanu absolūtos failu ceļos jebkurā ietvarā.
  • Zewo izmanto momentuzņēmumu 05–09-a Swift, kas nozīmē, ka tam ir grūtības ar veidošanu atbrīvošanas režīmā un tas jādarbina atkļūdošanas režīmā. Šī iemesla dēļ visi Zewo testi tika veikti ar Zewo būvētu un palaistu atkļūdošanas režīmā (bez atbrīvošanas optimizācijām).
  • Statiskā failu apstrāde ir diskusiju punkts starp servera puses ātrajiem ietvariem. Gan Vapor, gan Zewo iesaka izmantot Nginx kā starpniekserveri statiskas failu apstrādes gadījumā, pēc tam liekot ietvaru aiz šī pamata kā apstrādes jaudu. Perfekts iesaka izmantot viņu iebūvēto apdarinātāju, un es neesmu redzējis nevienu komentāru par IBM attiecībā uz viņu pašu viedokli par šo tēmu. Tā kā šis pētījums nebija par to, cik labi ietvari darbojas ar tādām iedibinātām servera lietojumprogrammām kā Nginx, statiskā failu apstrāde tika izmantota sākotnēji ar katru ietvaru. Varbūt jūs varēsit sasniegt labāku sniegumu gan Vapor, gan Zewo, ja izvēlēsities būvēt, paturot to prātā. Tas ir arī sekundārs iemesls, kāpēc es iekļāvu JSON testēšanu.
  • [Pievienots 1. septembris ar atjauninātiem rezultātiem] Zewo ir viena vītņota lietojumprogramma. Jūs varat iegūt papildu veiktspēju, palaižot vienu lietojumprogrammas gadījumu katram pieejamajam CPU, jo tie seko vienlaicīgam, nevis vairāku vītņu modelim. Šī pētījuma vajadzībām tika palaists tikai viens katras lietojumprogrammas piemērs.
  • Rīku ķēdes. Katrs ietvars veido atšķirīgu Apple momentuzņēmumu izstrādes momentuzņēmumu. Galīgās pārbaudes laikā tie bija / ir:   - ATTĪSTĪBA-SNAPSHOT-2016-08–24-a perfektam - ATTĪSTĪBA-SNAPSHOT-2016-07–25-a uzņēmumam Vapor & Kitura - ATTĪSTĪBA-SNAPSHOT-2016-05–09-a Zewo
  • Vapor ir īpaša sintakse darbības izlaišanai. Ja jūs vienkārši izpildāt bināro, jūs iegūsit papildu konsoles reģistrēšanu, kas paredzēta izstrādes un atkļūdošanas procesam. Tam ir mazliet virs galvas. Lai palaistu Vapor atbrīvošanas režīmā, jums tas jāpievieno
- env ​​= ražošana

izpildāmajam. t.i.

.build / release / App --env = produkcija
  • [Pievienots 1. septembris ar atjauninātiem rezultātiem] Strādājot ar Zewo, kaut arī jūs nevarat ātri izveidot atbrīvošanas režīmā rīku ķēdē 05–09-a, varat pievienot dažas atbrīvošanas režīma optimizācijas, izpildot šos argumentus:
ātra uzbūve -Xswiftc -O
  • Node.js / Express neveido un neatšķir atkļūdošanu / izlaišanu
  • Statiskā failu apstrāde ir iekļauta Vapor noklusējuma starpprogrammatūrā. Ja jūs neizmantojat statiskus failus un vēlaties optimizēt ātrumu, jums jāiekļauj (kā es to izdarīju VaporJSON):
drop.middleware = []

Kāpēc Node.js / Express?

Es nolēmu iekļaut emuāra variantu, izmantojot Node.js Express ietvaru. Tas ir labs salīdzinājums, jo tam ir ļoti līdzīga sintakse ar Server-Side Swift un tas tiek plaši izmantots. Tas palīdz izveidot labu bāzes līniju, lai parādītu, cik iespaidīgs var būt Swift.

Emuāru izstrāde

Kādā brīdī es sāku to dēvēt par “pakaļdzīšanās bumbiņu pakaļdzīšanos”. Pašreizējie servera puses Swift ietvari tiek ļoti aktīvi attīstīti, tāpat kā Swift 3, un katram ir ton izmaiņu salīdzinājumā ar iepriekšējām versijām. To pastiprināja bieža visu servera puses Swift ietvaru, kā arī Apple Swift komandas izlaišana. Neviena no tām šajā brīdī nebija īpaši pilnīga dokumentācijā, tāpēc es esmu ļoti pateicīga pamatkomandu dalībniekiem un visai Server-Side Swift kopienai par viņu ieguldījumu. Es esmu arī pateicīgs par palīdzību, kuru neskaitāmi kopienas locekļi un ietvarstruktūras komandas man sniedza. Tas bija ļoti jautri, un es to darīšu atkal, nedomājot.

Kā blakus piezīme, kaut arī licence nepieprasīja attiecināšanu, es uzskatu, ka ir patīkami atzīmēt, ka visi avotos iekļautie nejauši bezmaksas attēli ir no Pixbay un mani izvēlējās nejauši. Šādi avoti ievērojami atvieglo demonstrācijas projektus.

Hostings un vide

Lai samazinātu jebkādas atšķirības vidē, es paņēmu 2012. gada Mac Mini un devu tīru El Capitan instalāciju (10.11.6). Pēc tam es lejupielādēju un instalēju Xcode 8 beta 6 un iestatīju komandrindas rīkus uz Xcode 8. No turienes es instalēju swiftenv, instalēju nepieciešamos momentuzņēmumus, klonēju repos un tīri veidoju katru no emuāriem, atkal atbrīvošanas režīmā, kur iespējams. Es nekad nebraucu vairāk par vienu vienlaikus, un katrs tika apturēts un atsākts starp testiem. Pārbaudes servera specifikācijas ir:

Attīstībai es izmantoju 2015. gada rMBP. Šeit vadīju būvēšanas laika testus, jo šī ir mana reālās dzīves attīstības mašīna un tai bija vislielākā jēga. Es izmantoju wrk, lai iegūtu etalonus, un es to izdarīju virs tilta ar pērkona skrūvēm, izmantojot thunderbolt 2 kabeli starp mašīnām. Izmantojot pērkona skrūvju tiltu, pārliecinieties, ka jums ir neticami daudz joslas platuma un ka šī uzdevuma vietā jūs nenosakāt sava maršrutētāja ierobežojumus. Turklāt ir ticamāk, ja emuārus apkalpo vienā mašīnā un slodzes ģenerēšanai izmanto atsevišķu, jaudīgāku mašīnu, nodrošinot, ka jūs spējat pārspīlēt serveri, lai jūs būtu pārliecināts, ka tas nav ierobežojums. Tas arī nodrošina pastāvīgu testēšanas vidi, tāpēc varu teikt, ka katrs emuārs tika darbināts ar to pašu aparatūru un ar vienādiem nosacījumiem. Interesentiem manas mašīnas specifikācijas ir:

Benchmarking piezīmes

Etalona noteikšanai es nolēmu izmantot desmit minūšu testu ar četriem pavedieniem, no kuriem katrs satur 20 savienojumus. Četras sekundes nav pārbaude. Desmit minūtes ir saprātīgs laika posms, lai iegūtu daudz datu, un 20 savienojumu vadīšana četros pavedienos ir smaga emuāru slodze, bet ne satraucoša slodze.

Avota kods

Ja vēlaties izpētīt projektu avota kodus vai veikt kādu no saviem testiem, testēšanai izmantoto kodu es apvienoju vienā repozitorijā, kas atrodams vietnē:

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

Detalizēti rezultāti

Veidot laiku

Es domāju, ka būtu jautri vispirms palūkoties uz celtniecības laikiem. Laika veidošanai var būt liela loma ikdienas attīstībā, un, lai gan tam ir maz sakara ar ietvara izpildījumu, es domāju, ka varētu būt jautri izpētīt reālos skaitļus salīdzinājumā ar to, cik ilgi lietas jutās, kamēr es gaidīju.

Kas tika palaists

Par katru ietvaru

ātra uzbūve - tīrīšana = dist

un tad

laiks ātri izveidot

tika vadīti, kam sekoja otrais tests

ātri uzkopt - tīru

tad:

laiks ātri izveidot

Tas ietekmē gan pilnīgu veidošanu, ieskaitot atkarību no SPM izmantošanu, gan regulāru, tīru būvi ar jau lejupielādētām atkarībām.

Kā tas tika vadīts

Tas tika palaists manā vietējā 2015. gada rMBP, un visas versijas tika izveidotas atkļūdošanas režīmā, jo tas ir parasts process, izstrādājot programmatūru Swift.

Veidot laika rezultātus

Atmiņas lietošana

Otrā lieta, ko apskatīju, bija katra noslogotā karkasa atmiņas pēdas.

Kas bija Run

1. sākums - atmiņas pēdas nospiedums (procesu tikai skatīja)
2. - maksimālā atmiņa Procesa izmantošana manā testa serverī, izmantojot:

wrk -d 1m -t 4 -c 10

3. - otrā testa atkārtojums, izmantojot:

wrk -d 1m -t 8 -c 100

Kā tas bija Run

Šis tests tika veikts tīrā Mac mini, kas bija paredzēts kā testa serveris. Katrs ietvars tika būvēts atbrīvošanas režīmā, kur tas bija iespējams. No komandrindas vienlaikus tika palaists tikai viens ietvars, un tas tika atsākts starp testiem. Vienīgais testēšanas laikā atvērtais logs bija aktivitātes monitors, kuru es izmantoju, lai vizualizētu maksimālo atmiņas lietojumu. Kad katrs ietvars tika palaists, es vienkārši atzīmēju visaugstāko vērtību, kas parādījās aktivitātes monitora logā.

Atmiņas lietošanas rezultāti

Vītnes lietošana

Trešā lieta, ko es apskatīju, bija katra karkasa diegu izmantošana zem slodzes.

Kas bija Run

1. sākums - pavedieni (tikai skatījos procesu)
2. - maksimālā pavediena procesa izmantošana manā testa serverī, izmantojot:

wrk -d 1m -t 4 -c 10

Kā tas bija Run

Šis tests tika veikts tīrā Mac mini, kas bija paredzēts kā testa serveris. Katrs ietvars tika veidots atbrīvošanas režīmā, kur tas bija iespējams (vairāk par to ir metodoloģijas sadaļā). No komandrindas vienlaikus tika palaists tikai viens ietvars, un tas tika atsākts starp testiem. Pārbaudes laikā vienīgais atvērtais logs bija aktivitātes monitors, kuru es izmantoju, lai vizualizētu diega lietojumu. Kad katrs ietvars tika palaists, es vienkārši atzīmēju visaugstāko vērtību, kas parādījās aktivitātes monitora logā testa darbības laikā.

Piezīme par šiem rezultātiem

Šajā kategorijā nav uzvarētāju. Daudzas lietojumprogrammas pavedienus traktē atšķirīgi, un šie ietvari nav izņēmums. Piemēram, Zewo ir viena vītņota lietojumprogramma, un tā nekad neizmanto vairāk kā vienu (rediģēt: bez jūsu iejaukšanās, lai to darbinātu katrā CPU vienlaicīgā konfigurācijā). No otras puses, perfekts izmantos vienu no pieejamajiem CPU. Vapor katram savienojuma modelim izmantos vienu. Šis grafiks kā tāds tika izveidots tā, lai slodzes pavedienu tapas būtu viegli redzamas, jo abos grafikos tie atrodas vienā secībā.

Vītņu lietošanas rezultāti

Emuāru etaloni

Pirmais etalons ir / emuāra ceļš katrā, tā ir lapa, kurā katram pieprasījumam tiek parādīti 5 izlases attēli un viltus emuāra ziņas.

Kas bija Run

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

tika palaists katram emuāram no mana rMBP virs mana pērkona skrūvju tilta.

Kā tas bija Run

Tāpat kā atmiņas testēšana, katrs ietvars tika palaists atbrīvošanas režīmā, kur tas bija iespējams, un pirms katra testa tika apturēts un atsākts. Vienā brīdī serverī darbojās tikai viens ietvars. Testa laikā abām mašīnām tika veiktas visas darbības, lai vide būtu pēc iespējas līdzīgāka.

Rezultāti

Šis attēls tika atjaunināts 2016. gada 1. septembrī ar labojumuŠis attēls tika atjaunināts 2016. gada 1. septembrī ar labojumu

JSON etaloni

Tā kā daži apstrādāja statiskos failus, radās sarežģījumi, uzskatīja, ka ir taisnīgāk atkal veikt tos pašus testus, izmantojot vienkāršāku saskarni, tāpēc katras lietojumprogrammas versijas, kas tiek smilškastē ievietotas / json maršrutā, pievienoju desmit nejaušus skaitļus 0 robežās. –1000. Tie ir atsevišķi, lai pārliecinātos, ka statiskie failu apstrādātāji un starpprogrammatūra netraucē rezultātiem.

Kas bija Run

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

tika veikts katram JSON projektam.

Kā tas bija Run

Tāpat kā citu testu gadījumā katru ietvaru, ja iespējams, darbināja atbrīvošanas režīmā, un pirms katra testa tas tika apturēts un atsākts. Vienā brīdī serverī darbojās tikai viens ietvars. Testa laikā abām mašīnām tika veiktas visas darbības, lai vide būtu pēc iespējas līdzīgāka.

Rezultāti

Šis attēls tika atjaunināts 2016. gada 1. septembrī ar labojumuŠis attēls tika atjaunināts 2016. gada 1. septembrī ar labojumu

Secinājumi

Uz manu jautājumu atbildēja ar pārliecinošu JĀ. Swift ir vairāk nekā spējīgs izmantot izveidotos servera puses ietvarus. Ne tikai tas, bet arī visi servera puses Swift ietvari darbojās neticami labi, un Node.js katrā testā pieveica vismaz divus no tiem.

Ņemot vērā servera puses Swift, var ietaupīt neprātīgi daudz laika, lai dalītos savā kodu bāzē ar citām Swift lietotnēm, dažādu servera puses Swift ietvaru funkciju komplektiem un šeit redzamajiem rezultātiem, es teiktu, ka servera puses Swift darbojas labi veids, kā būt ļoti lielam pretendentam programmēšanas arēnā. Es personīgi pēc iespējas vairāk plānoju Sviftā, it īpaši servera pusē, un nevaru gaidīt, kad redzēšu visus neticamos projektus, kas parādīsies ārpus kopienas!

Iesaistīties

Ja jūs interesē Swift servera pusē, tagad ir īstais laiks tajā iesaistīties! Joprojām ir daudz darāmā ar ietvariem, to dokumentēšanu un patiešām atdzist lietojumprogrammu kā piemēru iegūšanu, atvērtu vai slēgtu avotu. Jūs varat uzzināt vairāk par katru sistēmu un iesaistīties šeit:

Lieliski: vietne | Github | Ļengans | Gitter
Vapor: vietne | Github | Lieki
Kitura: vietne | Github | Gitter
Zewo: vietne | Github | Lieki

Sazināties

Ja vēlaties izveidot savienojumu, varat sazināties ar mani @rymcol vietnē Twitter.

Informācijas atklāšana, kas, manuprāt, bija nepieciešama: Lai rediģētu dažus datus pēc tam, kad Zewo tika optimizētas versijas, tika izmantota rediģēšana, lai koriģētu dažus datus, izmantojot metodi, kas aizstāj ar “ātru build-c release”. PerfectlySoft Inc. piekrita finansēt šo pētījumu man, lai popularizētu Swift spēku. Es darbojos arī Perfect & Vapor apvienotajās grupās, lai arī neesmu neviena no tām darbinieks, un arī mans viedoklis neatspoguļo viņu viedokli. Es esmu darījis visu iespējamo, lai paliktu objektīvs, attīstoties visām četrām platformām, un es patiesi vēlējos redzēt rezultātus. Viss kods ir publiski pieejams šim pētījumam, lūdzu, jūtieties brīvi to pārbaudīt vai atkārtot dažus testus un pārbaudīt pats!