Бенчмарки за най-добрите Swift рамки от страна на сървъра спрямо Node.js

Редактиране на 7 октомври: Поръчка за Моите последващи действия: Бенчмарки за Linux (Ubuntu)

Въведение

Наскоро работех в Server-Side Swift и ми беше зададен въпросът:

„Може ли сървъра Swift да победи Node.js?“

Swift като основен език за всичко, включително сървъра, е интригуващ, тъй като за първи път беше отворен и пренесен в Linux. Много от вас със сигурност са толкова любопитни, колкото и аз, така че с удоволствие споделям резултатите от своето проучване тук.

Най-добрите бързи рамки от страната на сървъра

Към момента на писането, топ сървърните рамки от страна на сървъра (изброени в реда на звездите в GitHub) са:

  • Перфектен ️ 7 956
  • Парни ️5,183
  • Kitura ,04,017
  • Zewo ️1,186

Организация на този пост

Този документ е формулиран по следния начин:

  • Това бързо въведение
  • Обобщение на резултатите
  • методология
  • Подробни резултати
  • Заключение и заключителни бележки

Обобщение на резултатите

Следва кратко резюме на основните показатели и ще кажа това тук:

Без значение от индивидуалното класиране, всички тези рамки се представиха невероятно добре, Swift последователно победи Node.js и всички бяха много забавни за работа.
Това изображение е актуализирано на 1 септември 2016 г. с корекция

Методология и бележки

Защо да използвате блогове и JSON?

Най-просто, блоговете са нещо повече от връщане на "Здравей, свят!", А JSON е много често използван случай. Добрите показатели се нуждаят от подобно натоварване на всяка рамка и трябваше да бъде малко по-голямо натоварване при отпечатването на две думи на екрана.

Поддържане на нещата еднакви

Една от основните теми, на която се опитах да се придържам, беше да поддържам всички блогове възможно най-сходни един с друг, докато все още се развивам в стила и синтаксиса на всяка рамка. Много от структурите, като генериране на съдържание, се повтарят дословно, така че всяка рамка има едни и същи модели данни, с които да работи, но фасети като маршрутизиране на URL понякога са изключително различни, за да се впишат в синтаксиса и стила на всяка рамка.

Фини разлики

Има някои фини разлики, които трябва да се отбележат между сървъра Swift Frameworks.

  • И Kitura, и Zewo имат проблеми с изграждането, ако има някакви интервали в техните абсолютни файлови пътища. Xcode също има проблеми с изграждането на интервали в абсолютни файлови пътища във всяка рамка.
  • Zewo използва моментната снимка 05–09-a Swift, което означава, че има проблеми с изграждането в режим на освобождаване и трябва да се стартира в режим на отстраняване на грешки. Всички тестове на Zewo бяха извършени със Zewo, изградена и работеща в режим на отстраняване на грешки (без оптимизации за освобождаване) по тази причина.
  • Статичното обработване на файлове е въпрос на дебат сред бързите рамки от страна на сървъра. И Vapor и Zewo препоръчват използването на Nginx като прокси за обработка на статични файлове, след което поставянето на рамката зад това като мощност за обработка на задния ред. Перфектно предлага да използвате вградения им манипулатор и не съм виждал коментари на IBM по отношение на техните собствени възгледи по темата. Тъй като това проучване не беше за това колко добре работят рамките с установени сървърни приложения като Nginx, статичното обработване на файлове се използва родно с всяка рамка. Възможно е да успеете да постигнете по-добри резултати както в Vapor, така и в Zewo, ако решите да изградите това предвид. Това също е вторична причина, че включих JSON тестване.
  • [Добавено на 1 септември с актуализирани резултати] Zewo е приложение с една нишка. Можете да получите допълнителна производителност от него, като стартирате по един екземпляр от приложението на наличен процесор, тъй като те следват едновременно, а не многопоточен модел. За целите на това проучване е изпълнен само един екземпляр от всяко приложение.
  • Toolchains. Всяка рамка изгражда различна верига от инструменти за моментни разработки от Apple. По време на окончателното тестване те са:
     
    - РАЗВИТИЕ-SNAPSHOT-2016-08–24-a за Перфектно
    - РАЗВИТИЕ-SNAPSHOT-2016-07–25-a за Vapor & Kitura
    - РАЗВИТИЕ-SNAPSHOT-2016-05–09-a за Zewo
  • Vapor има специален синтаксис за пускане на версии. Ако просто изпълнявате двоичния файл, ще получите допълнително регистриране на конзолата, което трябва да помогне за процеса на разработване и отстраняване на грешки. Това е малко над главата. За да стартирате Vapor в режим на освобождаване, трябва да добавите
--env = производството

до изпълнимия файл. т.е.

.build / release / App --env = производство
  • [Добавено на 1 септември с актуализирани резултати] Когато работите с Zewo, въпреки че не можете да изграждате с бърз режим на освобождаване на 05-09-та верига с инструменти, можете да добавите някои оптимизации на режима на пускане, като прехвърлите тези аргументи:
бързо изграждане -Xswiftc -O
  • Node.js / Express не изгражда, нито прави разлика между отстраняване на грешки / освобождаване
  • Статичното обработване на файлове е включено в софтуера по подразбиране на Vapor. Ако не използвате статични файлове и искате да оптимизирате скоростта, трябва да включите (както направих в VaporJSON):
drop.middleware = []

Защо Node.js / Express?

Реших да включа вариант на блога, използвайки Express Express рамката в Node.js. Това е добро сравнение, тъй като има много сходен синтаксис с Swift от страна на сървъра и се използва широко. Той помага да се установи добра базова линия, която да покаже колко впечатляващ може да бъде Swift.

Разработване на блоговете

В един момент започнах да наричам това „гонене на подскачащата топка“. Настоящите рамки на сървъра Swift са в процес на много активно развитие, както и Swift 3 и всяка от тях има поредица от промени от предишните си версии. Това стана усилено от честите издания от всички сървъри Swift Frameworks, както и от екипа на Swift в Apple. Към този момент никой от тях не е особено пълен в документацията си, така че съм много благодарен на членовете на рамковите екипи и на общността на сървъра Swift като цяло за техния принос. Благодарен съм също за помощта, която ми оказаха безброй членове на общността и рамкови екипи. Беше много забавно и бих го направила отново, без да се замислям.

Като странична бележка, въпреки че приписването не се изисква от лиценза, чувствам, че е хубаво да отбележа, че всички случайни безплатни снимки, включени в източниците, са от Pixbay и са избрани от мен на случаен принцип. Източници като този правят демо проектите много по-лесни.

Хостинг и околна среда

За да минимизирам всякакви различия в средата, взех 2012 Mac Mini и му дадох чиста инсталация на El Capitan (10.11.6). След това изтеглих и инсталирах Xcode 8 beta 6 и настроих инструментите на командния си ред на Xcode 8. От там инсталирах swiftenv, инсталирах необходимите снимки, клонирах repos и чисто изградих всеки от блоговете, отново в режим на освобождаване, където възможен. Никога не бягах повече от един по един и всеки беше спрян и рестартиран между тестовете. Характеристиките на тестовия сървър са:

За развитие използвам 2015 rMBP. Тук проведох тестовете за време за изграждане, тъй като това е моята машина за развитие в реалния живот и това имаше най-голям смисъл. Използвах wrk за получаване на референтните стойности и направих това през гръмотевичен мост с помощта на кабел thunderbolt 2 между машините. Използването на гръмотевичен мост гарантира, че имате невероятно количество честотна лента и че не сравнявате ограниченията на вашия рутер, вместо задачата под ръка. Освен това е по-надеждно да обслужвате блоговете на една машина и да използвате отделна, по-мощна машина за генериране на натоварването, като гарантирате, че сте способни да надмогнете сървъра, така че да сте сигурни, че това не е ограничение. Това също ви дава постоянна тестова среда, така че мога да кажа, че всеки блог е стартиран на един и същ хардуер и при същите условия. За любопитните, спецификациите на моята машина са:

Бележки за сравняване

За сравнителен анализ реших да използвам десетминутен тест с четири нишки, всеки от които носи 20 връзки. Четири секунди не е тест. Десет минути е разумен период от време за получаване на много данни, а осъществяването на 20 връзки в четири нишки е сериозно натоварване за блоговете, но не и скъсяващо натоварване.

Програмен код

Ако искате да проучите изходния код за проектите или да направите свое собствено тестване, консолидирах кода, използван за тестване, в едно хранилище, намерено на:

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

Подробни резултати

Време за изграждане

Мислех, че би било забавно първо да разгледаме времената на изграждане. Времето за изграждане може да играе голяма роля в ежедневното развитие и макар да има малко общо с представянето на рамката, мислех, че може да е забавно да изследвам реални числа спрямо колко дълго се чувствах нещата, докато чаках.

Какво беше пуснато

За всяка рамка

бързо изграждане --clean = dist

и тогава

време бързо изграждане

бяха пуснати, последвани от втори тест на

бързо изграждане - чист

тогава:

време бързо изграждане

Този фактор е както цялостно изграждане, включително издърпване на зависимости със SPM, така и редовно, чисто изграждане с вече изтеглени зависимости.

Как се провеждаше

Това беше стартирано в моя локален 2015 rMBP и всички компилации бяха извършени в режим на отстраняване на грешки, тъй като това е нормалният процес при разработването на софтуер на Swift.

Време за изграждане на резултати

Използване на паметта

Второто нещо, което разгледах, беше отпечатъкът на паметта на всяка рамка под товар.

Какво беше Run

1-во - начален отпечатък на паметта (току-що загледах процеса)
Второ - Пикова памет Използване на процеса на моя тестов сървър, използвайки:

wrk -d 1m -t 4 -c 10

3-то - Повторение на втория тест с използване на:

wrk -d 1m -t 8 -c 100

Как беше Run

Този тест се изпълнява на чист Mac mini, посветен като тестов сървър. Всяка рамка е изградена в режим на освобождаване, където е възможно. От командния ред в даден момент се изпълняваше само една рамка и тя беше рестартирана между тестовете. Единственият друг отворен прозорец към момента на тестване беше мониторът на активността, който се използва от мен за визуализиране на пиково използване на паметта. Докато се изпълняваше всяка рамка, просто отбелязах най-високата стойност, която се появи в прозореца на монитора на активността.

Резултати от използването на паметта

Използване на нишката

Третото нещо, което разгледах, беше използването на конци на всяка рамка под товар.

Какво беше Run

1-во - начални нишки (току-що загледахте процеса)
Второ - Използване на пикова нишка на процеса на моя тестов сървър, използвайки:

wrk -d 1m -t 4 -c 10

Как беше Run

Този тест се изпълнява на чист Mac mini, посветен като тестов сървър. Всяка рамка е изградена в режим на освобождаване, където е възможно (повече за това е в раздела за методологията). От командния ред в даден момент се изпълняваше само една рамка и тя беше рестартирана между тестовете. Единственият друг отворен прозорец към момента на тестване беше мониторът на активността, който се използва от мен за визуализиране на използването на конци. Докато се изпълняваше всяка рамка, просто отбелязах най-високата стойност, която се появи в прозореца на монитора на активността, докато тестът работи.

Бележка за тези резултати

В тази категория няма „победа“. Много приложения третират нишките по различен начин и тези рамки не са изключение. Например, Zewo е едно резбовано приложение и никога няма да използва повече от едно (редактиране: без вашата намеса да го стартирате на всеки процесор в паралелна конфигурация). Perfect, от друга страна, ще използва един на наличен процесор. Парата ще използва един за модел на връзка. Като такава, тази графика е проектирана така, че шиповете в нишките под товар са лесно видими, тъй като те са в един и същ ред и в двете графики.

Резултати от използването на нишки

Бенч бенчмарки

Първият показател е маршрутът / блог във всяка, който е страница, която връща 5 произволни изображения и фалшиви публикации в блога за всяка заявка.

Какво беше Run

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

беше пуснат за всеки блог от моя rMBP през моста на гръмотевичния мост.

Как беше Run

Както при тестването на паметта, всяка рамка се изпълняваше в режим на освобождаване, когато беше възможно, и беше спряно и рестартирано преди всеки тест. Само един фреймвор се изпълняваше в даден момент на сървъра. По време на изпитването цялата активност беше минимална за двете машини, за да се поддържа околната среда възможно най-сходна.

Резултати

Това изображение е актуализирано на 1 септември 2016 г. с корекцияТова изображение е актуализирано на 1 септември 2016 г. с корекция

JSON Бенчмарки

Поради някои усложнения как всички обработват статични файлове, се почувства по-справедливо отново да се изпълняват едни и същи тестове, като се използва по-прост интерфейс, така че добавих версии на всяко приложение, които са в пясъчна кутия към / json маршрут, който връща десет произволни числа в рамките на 0 -1000. Те са отделни, за да се уверят, че статичните файлове и междинен софтуер не пречат на резултатите.

Какво беше Run

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

се изпълняваше за всеки проект JSON.

Как беше Run

Както при другите тестове, всяка рамка се изпълняваше в режим на освобождаване, когато е възможно, и беше спряна и рестартирана преди всеки тест. Само един фреймвор се изпълняваше в даден момент на сървъра. По време на изпитването цялата активност беше минимална за двете машини, за да се поддържа околната среда възможно най-сходна.

Резултати

Това изображение е актуализирано на 1 септември 2016 г. с корекцияТова изображение е актуализирано на 1 септември 2016 г. с корекция

Заключения

На въпроса ми беше отговорено с огромно ДА. Swift е повече от способен да поеме установените рамки от страна на сървъра. Не само това, но всички сървъри Swift Frameworks се представиха невероятно добре и Node.js беше победен от поне двама от тях при всеки тест.

Предвид сървъра Swift може да спести безумно количество време за споделяне на кодовата му база с другите ви приложения на Swift, наборите от функции на различните рамки на Swift от страна на сървъра и резултатите тук, бих казал, че Swift от страна на сървъра е добре начин да бъдеш много голям претендент в арена за програмиране. Аз лично програмирам възможно най-много в Swift, особено от страна на сървъра, и нямам търпение да видя всички невероятни проекти, които ще изплуват извън общността!

Включете се

Ако се интересувате от сървъра Swift, сега е моментът да се включите! Предстои да се свърши много работа по рамките, тяхната документация и получаване на наистина страхотни приложения като примери, отворен или затворен код. Можете да научите повече за всяка рамка и да се включите тук:

Перфектен: Уебсайт | Github | Отпуснат | Gitter
Парите: Уебсайт | Github | застой
Kitura: Уебсайт | Github | Gitter
Zewo: Уебсайт | Github | застой

Влезте във връзка

Ако искате да се свържете, можете да се свържете с мен @rymcol в Twitter.

Разкрития, които чувствах, че са необходими: Редакции бяха добавени на 1 септември 2016 г., за да коригират някои данни, след като бяха направени оптимизации за изданието за Zewo, използвайки метод, алтернативен на „бързото издание -c”. PerfectlySoft Inc. се съгласи да финансира това проучване за мен, за да промотира силата на Swift. Освен това съм в екипите на Github за Perfect & Vapor, въпреки че не съм служител нито в нито един, нито моите мнения отразяват тяхното. Направих всичко възможно да остане безпристрастен, тъй като се развивам във всичките четири платформи и бях истински любопитен да видя резултатите. Целият код е публично достъпен за това проучване. Моля, не се колебайте да го проверите или повторите някои от тестовете и да го проверите сами!