Benchmarky pro hlavní serverové swiftové rámce vs. Node.js

Upravit 7. října: Checkout my Follow Up: Benchmarks for Linux (Ubuntu)

Úvod

Nedávno jsem pracoval na serveru na straně Swift a byl mi položen dotaz:

"Může server-Side Swift porazit Node.js?"

Swift jako primární jazyk pro všechno, včetně serveru, byl zajímavý od doby, kdy byl poprvé otevřen a přenesen na Linux. Mnozí z vás jsou jistě tak zvědaví, jako jsem já, takže jsem velmi rád, že zde mohu sdílet výsledky své studie.

Nejlépe Swift Framework na straně serveru

V době psaní jsou nejlepší Swift Framework na straně serveru (uvedené v pořadí hvězd na GitHubu):

  • Perfektní ️7 956
  • Várka - 5 183
  • Kitura 4 047
  • Zewo -1 186

Organizace tohoto příspěvku

Tento dokument je rozložen následujícím způsobem:

  • Toto rychlé intro
  • Shrnutí výsledků
  • Metodologie
  • Podrobné výsledky
  • Závěr a závěrečné poznámky

Shrnutí výsledků

Následuje stručný souhrn primárních standardů a řeknu to zde:

Bez ohledu na individuální hodnocení, všechny tyto rámce fungovaly neuvěřitelně dobře, Swift neustále porazil Node.js a všichni se s nimi hodně bavili.
Tento obrázek byl opraven 1. září 2016 opravou

Metodika a poznámky

Proč používat blogy a JSON?

Nejjednodušší je, že blogy víc než vracejí „Ahoj, svět!“, A JSON je velmi běžný případ použití. Dobré měřítka vyžadují podobné zatížení v každém rámci a muselo být o něco větší zatížení než tisknout dvě slova na obrazovku.

Udržovat věci stejné

Jedním z hlavních témat, které jsem se snažil držet, bylo udržovat všechny blogy co nejpodobnější jeden druhému, zatímco se stále vyvíjely ve stylu a syntaxi každého rámce. Mnoho struktur, jako je generování obsahu, se opakuje v doslovném znění, takže každý rámec má stejné datové modely, se kterými může pracovat, ale aspekty jako URL směrování jsou někdy výrazně odlišné, aby odpovídaly syntaxi a stylu každého rámce.

Jemné rozdíly

Mezi drobnými rozdíly mezi serverem na straně serveru Swift Framework existují určité jemné rozdíly.

  • Kitura i Zewo mají problémy s budováním, pokud jsou v jejich absolutních souborových cestách nějaké mezery. Xcode má také problémy s vytvářením mezer v absolutních souborových cestách v libovolném rámci.
  • Zewo používá snímek Swift 05–09-a, což znamená, že má potíže s budováním v režimu uvolnění a musí být spuštěno v režimu ladění. Všechny testy Zewo byly z tohoto důvodu provedeny se sestavením a spuštěním Zewo v režimu ladění (bez optimalizace vydání).
  • Statické zpracování souborů je bodem debaty mezi serverovými postranními rámci. Vapor i Zewo doporučují používat Nginx jako proxy pro práci se statickými soubory, a poté za rámec umístit rámec jako výpočetní sílu pro backend. Perfect navrhuje používat jejich vestavěný handler a já jsem neviděl žádné komentáře k IBM ohledně jejich vlastních názorů na toto téma. Protože tato studie nebyla o tom, jak dobře fungují rámce s zavedenými serverovými aplikacemi, jako je Nginx, při každém rámci bylo nativní použití statického zpracování souborů. Možná se vám podaří dosáhnout lepšího výkonu jak ve Vapor, tak ve Zewo, pokud se rozhodnete stavět s tím na paměti. To je také vedlejší důvod, proč jsem zahrnul testování JSON.
  • [Přidáno 1. září s aktualizovanými výsledky] Zewo je aplikace s jedním vláknem. Můžete z toho získat další výkon spuštěním jedné instance aplikace na dostupný procesor, protože sledují souběžný, nikoli vícevláknový model. Pro účely této studie byla spuštěna pouze jedna instance každé aplikace.
  • Toolchains. Každý rámec staví jinou nástrojovou sadu vývojových snímků od společnosti Apple. V době závěrečného testování to byly:
     
    - DEVELOPMENT-SNAPSHOT-2016-08–24-a pro Perfect
    - DEVELOPMENT-SNAPSHOT-2016-07–25-a pro Vapor & Kitura
    - DEVELOPMENT-SNAPSHOT-2016-05-09-a pro Zewo
  • Vapor má speciální syntaxi pro spouštění vydání. Pokud jednoduše spustíte binární kód, získáte další protokolování konzoly, které má pomoci s procesem vývoje a ladění. To má trochu režii. Chcete-li spustit Vapor v režimu uvolnění, musíte přidat
--env = produkce

na spustitelný soubor. tj.

.build / release / App --env = production
  • [Přidáno 1. září s aktualizovanými výsledky] Při práci se Zewo, i když se nemůžete stavět s rychlým uvolňováním v režimu vydání na nástrojové liště 05–09-a, můžete přidat některé optimalizace režimu uvolnění předáním těchto argumentů:
rychlé sestavení -Xswiftc -O
  • Node.js / Express se nevytváří ani nerozlišuje mezi debug / release
  • Statické zpracování souborů je součástí výchozího softwaru Vapor. Pokud nepoužíváte statické soubory a chcete optimalizovat rychlost, musíte zahrnout (stejně jako ve VaporJSON):
drop.middleware = []

Proč Node.js / Express?

Rozhodl jsem se zahrnout variantu blogu pomocí rámce Express v Node.js. Toto je dobré srovnání, protože má velmi podobnou syntaxi jako na straně serveru a je široce používáno. Pomáhá vytvořit dobrou základní linii a ukázat, jak působivý může být Swift.

Vývoj blogů

V určitém okamžiku jsem to nazval „pronásledováním skákací koule“. Současné rámce na straně serveru Swift se vyvíjejí velmi aktivně, stejně jako Swift 3, a každý z nich má spoustu změn oproti předchozím verzím. To se zesílilo častými vydáváními ze všech serverových swiftových rámců a týmu Swift u společnosti Apple. Žádný z nich nebyl v této chvíli ve své dokumentaci zvlášť kompletní, takže jsem velmi vděčný členům rámcových týmů a komunitě Swift na straně serveru za jejich příspěvky. Jsem také vděčný za pomoc, kterou mi na cestě dalo nespočet členů komunity a týmy rámců. Byla to spousta legrace a udělal bych to znovu bez přemýšlení.

Jako vedlejší poznámka, i když v licenci to nebylo vyžadováno, mám pocit, že je hezké si uvědomit, že všechny náhodné obrázky bez licenčních poplatků obsažené ve zdrojích pocházejí z Pixbay a byly náhodně vybrány. Zdroje, jako je tento, usnadňují demo projekty.

Hosting a životní prostředí

Abychom minimalizovali jakékoli rozdíly v prostředí, vzal jsem si Mac Mac 2012 a dal jsem čistou instalaci El Capitan (10.11.6). Poté jsem stáhl a nainstaloval Xcode 8 beta 6 a nastavil jsem nástroje příkazového řádku na Xcode 8. Odtud jsem nainstaloval swiftenv, nainstaloval potřebné snímky, klonoval repozitáře a čistě budoval každý z blogů, znovu v režimu vydání, kde možný. Nikdy jsem neběžel více než jeden najednou a každý byl zastaven a restartován mezi testy. Specifikace testovacího serveru jsou:

Pro vývoj používám 2015 rMBP. Spustil jsem zde testy doby sestavení, protože to je můj stroj pro vývoj v reálném životě a to dávalo největší smysl. Použil jsem wrk k získání benchmarku, a udělal jsem to přes blesk thunderbolt pomocí blesku 2 thunderbolt mezi stroji. Použití blesku thunderbolt zajistí, že budete mít neuvěřitelné množství šířky pásma a že nebudete srovnávat omezení routeru, namísto úkolu. Je také spolehlivější obsluhovat blogy na jednom počítači a používat samostatný, výkonnější stroj pro generování zátěže, což zajišťuje, že jste schopni přemoci server, takže si můžete být jisti, že to není omezení. To také poskytuje konzistentní testovací prostředí, takže mohu říci, že každý blog byl spuštěn na stejném hardwaru a za stejných podmínek. Pro zvědavé jsou specifikace mého stroje:

Srovnávací poznámky

Pro benchmarking jsem se rozhodl použít desetiminutový test se čtyřmi vlákny, z nichž každý nese 20 spojení. Čtyři sekundy není test. Deset minut je rozumným časovým rámcem pro získání velkého množství dat a provoz 20 spojení na čtyřech vláknech je pro blogy statným nákladem, ale ne zlomovým zatížením.

Zdrojový kód

Pokud byste chtěli prozkoumat zdrojový kód projektů nebo provést vlastní testování, sloučil jsem kód použitý pro testování do jednoho úložiště, které najdete na adrese:

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

Podrobné výsledky

Budujte čas

Myslel jsem, že by bylo zábavné se nejprve podívat na časy sestavení. Budování času může hrát důležitou roli v každodenním vývoji ai když to má málo společného s výkonem rámce, domníval jsem se, že by bylo zábavné prozkoumat skutečná čísla vs. jak dlouho se věci cítily, když jsem čekal.

Co bylo spuštěno

Pro každý rámec

swift build --clean = dist

a pak

časově rychlé sestavení

byly spuštěny, následoval druhý test

rychlé sestavení - čistič

pak:

časově rychlé sestavení

Toto ovlivňuje jak kompletní sestavení, včetně vytahování závislostí s SPM, tak pravidelné, čisté sestavení s již staženými závislostmi.

Jak to bylo spuštěno

Toto bylo spuštěno na mém místním rMBP 2015 a všechny byly vytvořeny v ladicím režimu, protože to je normální proces při vývoji softwaru Swift.

Budujte výsledky času

Využití paměti

Druhou věcí, na kterou jsem se podíval, byla paměťová stopa každého rámce pod zatížením.

Co bylo Run

1. - spuštění stopy paměti (proces se právě objevil)
2. - Špičková paměť Využití procesu na mém testovacím serveru pomocí:

wrk -d 1m -t 4 -c 10

3. - Opakování druhého testu za použití:

wrk -d 1m -t 8 -c 100

Jak to bylo Run

Tento test byl proveden na čistém Mac mini určeném jako testovací server. Každý rámec byl podle možnosti vestavěn do režimu vydání. Z příkazového řádku byl současně spuštěn pouze jeden rámec a mezi testy byl restartován. Jediným dalším otevřeným oknem v době testování byl monitor aktivity, který jsem použil k vizualizaci využití špičkové paměti. Když byl každý rámec spuštěn, jednoduše jsem si všiml nejvyšší hodnoty, která se objevila v okně sledování aktivity.

Výsledky využití paměti

Použití závitu

Třetí věcí, na kterou jsem se podíval, bylo používání podprocesů každého rámce pod zatížením.

Co bylo Run

1. - startovací vlákna (proces se právě objevil)
2. - Špičkové vlákno Použití procesu na mém testovacím serveru pomocí:

wrk -d 1m -t 4 -c 10

Jak to bylo Run

Tento test byl proveden na čistém Mac mini určeném jako testovací server. Každý rámec byl postaven v režimu vydání, kde to bylo možné (více o tom je v sekci metodologie). Z příkazového řádku byl současně spuštěn pouze jeden rámec a mezi testy byl restartován. Jediným dalším otevřeným oknem v době testování byl monitor aktivity, který jsem použil k vizualizaci využití vlákna. Když byl každý rámec spuštěn, jednoduše jsem si všiml nejvyšší hodnoty, která se objevila v okně sledování aktivity, když byl test spuštěn.

Poznámka o těchto výsledcích

V této kategorii není „vítězství“. Mnoho aplikací zpracovává vlákna různě a tyto rámce nejsou výjimkou. Například Zewo je jednovláknová aplikace a nikdy nebude používat více než jednu (editace: bez vašeho zásahu pro spuštění na každém CPU v souběžné konfiguraci). Perfektní, na druhé straně, použije jeden na každý dostupný procesor. Vapor použije jeden pro každý model připojení. Jako takový byl tento graf navržen tak, aby hroty ve vláknech pod zatížením byly snadno viditelné, protože jsou ve stejném pořadí v obou grafech.

Výsledky použití vlákna

Benchmarky blogu

Prvním měřítkem je cesta / blog v každé, což je stránka, která vrací pro každou žádost 5 náhodných obrázků a falešných příspěvků na blogu.

Co bylo Run

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

byl spuštěn pro každý blog z mého rMBP přes můj blesk.

Jak to bylo Run

Stejně jako v případě testování paměti byl každý rámec spuštěn v režimu vydání, kde to bylo možné, a byl zastaven a restartován před každým testem. V daném okamžiku byl na serveru spuštěn pouze jeden rámec. Veškerá aktivita byla během testování provedena na minimu na obou strojích, aby se prostředí co nejvíce podobalo.

Výsledek

Tento obrázek byl opraven 1. září 2016 opravouTento obrázek byl opraven 1. září 2016 opravou

Benchmarky JSON

Kvůli některým komplikacím toho, jak každý zachází se statickými soubory, se cítilo spravedlivější znovu provádět stejné testy pomocí jednoduššího rozhraní, takže jsem přidal verze každé aplikace, které jsou izolovány na cestu / json, která vrací deset náhodných čísel v rámci 0 –1000. Jsou oddělené, aby se ujistil, že popisovače statického souboru a middleware neinterferují s výsledky.

Co bylo Run

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

byl spuštěn pro každý projekt JSON.

Jak to bylo Run

Stejně jako u ostatních testů byla každá framework spuštěna v uvolňovacím režimu, kde to bylo možné, a byla zastavena a restartována před každým testem. V daném okamžiku byl na serveru spuštěn pouze jeden rámec. Veškerá aktivita byla během testování provedena na minimu na obou strojích, aby se prostředí co nejvíce podobalo.

Výsledek

Tento obrázek byl opraven 1. září 2016 opravouTento obrázek byl opraven 1. září 2016 opravou

Závěry

Moje otázka byla zodpovězena drtivou ANO. Swift je více než schopen převzít zavedené rámce na straně serveru. Nejen to, ale všechny servery na straně serveru Swift Framework fungovaly neuvěřitelně dobře a Node.js byl v každém testu poražen nejméně dvěma z nich.

Vzhledem k tomu, že server-side Swift může ušetřit šílený čas sdílení jeho codebase s ostatními aplikacemi Swift, sadami funkcí různých server-side swift frameworků a výsledky zde, řekl bych, že server-side swift je na dobré způsob, jak být velmi velkým uchazečem v programovací aréně. Já osobně programuji v Swift co nejvíce, zejména na straně serveru, a nemůžu se dočkat, až uvidím všechny neuvěřitelné projekty, které vynoří z komunity!

Zapojte se

Pokud vás zajímá Server-Side Swift, nyní je čas se zapojit! Na rámcích, jejich dokumentaci a práci s některými opravdu skvělými aplikacemi jako příklady, otevřený nebo uzavřený zdroj, je stále třeba vykonat mnoho práce. Můžete se dozvědět více o každém rámci a zapojit se zde:

Perfektní: Web | Github | Slack | Gitter
Vapor: Webové stránky | Github | Slack
Kitura: Webové stránky | Github | Gitter
Zewo: Webové stránky | Github | Slack

Být v kontaktu

Pokud se chcete připojit, můžete se na mě obrátit na @rymcol na Twitteru.

Zveřejnění, která jsem cítil, byly nezbytné: Úpravy byly přidány 1. září 2016, aby se opravila některá data poté, co byly pro Zewo provedeny optimalizace vydání pomocí metody alternativní k `swift build -c release`. PerfectlySoft Inc. souhlasil s financováním této studie pro mě, k podpoře síly Swift. Jsem také v týmech githubů pro Perfect & Vapor, i když nejsem ani zaměstnancem, ani moje názory neodrážejí jejich. Udělal jsem, co bylo v mých silách, abych zůstal nestranný, jak se vyvíjím na všech čtyřech platformách, a byl jsem opravdu zvědavý na výsledky. Celý kód je pro tuto studii veřejně k dispozici, neváhejte a vyzkoušejte jej nebo opakujte některé testy a ověřte si to sami!