Всем доброго времени суток!
В этом году с выходом Flutter — фреймворка для кроссплатформенной разработки приложений наметился подъем хайпа по языку Dart. Как и любой перфекционист прокрастинирующий от скуки лентяй я задумался о сравнении производительности серверной реализации виртуальной машины Dart с ее потенциальным антагонистом в лице Node.js. Скажу сразу, что во мне теплилась надежда что Dart победит, а я обрету святой грааль дарующий мне превосходство над потенциальными конкурентами на ближайшие пару тройку пятилеток, но реальность оказалось немного иной...
Инструментарий
- Тестовая машина: Core I7, SSD, 12GB ОЗУ ( любезно предоставленная моим прошлым работодателем )
- Нагрузочное тестирование: k6.io ( кстати очень интересный по своей архитектуре фреймворк )
Организация кода приложений
Тут я особо решил не заморачиваться и решил следовать рекомендациям, которые вычитывал в свое время на Хабре. В частности:
- Добавил полезную нагрузку в качестве работы по генерации рандомных данных ( рандомных, чтобы исключить потенциальное кеширование результатов )
class Human {
constructor (id, name, surname, age, gender) {
this.id = id
this.name = name
this.surname = surname
this.age = age
this.gender = gender
}
}- Как в Dart так и в Node.js использовал варианты синхронной и асинхронной обработки запроса.
- Применил варианты нативных решений и варианты решений на отраслевых фреймворках (aqueduct for dart и express for node.js)
- Так как в ходе исследования удалось получить существенное ускорение работы Dart при использовании aqueduct, который запускает изоляты на каждом ядре, то для целей уравновешивания применил модуль cluster для node.js
Методика тестирования
- запускал нагрузочные тесты с заданным числом запросов в секунду (500, 750) и ограничением на количество итераций теста (количество завершенных запросов)
- как приложение так и тестирующий фреймворк были запущены на одной машине, соответственно стоит понимать, что все результаты являются относительными и могут быть сравнимы только друг с другом
Результаты
Native Dart
500 rps
750 rps
- http_reqs: 309.10154/s
Aqueduct framework for Dart
500 rps
750 rps
Native Node.js
500 rps
750 rps
Node Express with Cluster
500 rps
750 rps
Выводы
- Конечно многое зависит от того как Вы реализовали логику приложения, я не особо уверен, что мой код является оптимальным как в случае dart так и node.js
- В частности функцию генерации массива можно было вывести в отдельный worker поток с асинхронным выводом, в моем случае это не было реализовано, поэтому здесь на самом деле не использована вся мошь асинхронщины
- Как в Dart так и в Node.js вывод можно было организовать через поток
- Поэтому здесь еще много места как для исследования производительности, так и для оптимизаций
- Dart в нативной реализации хендлеров показал эпичейский фейл, тем не менее при реализации через фреймворк показал впечатляющие результаты, согласно которым виртуальная машина Dart уже сейчас может составить конкуренцию Node.js
- На сколько я знаю, в оптимизацию работы V8 вложено колоссальное количество человеко-часов труда, я более чем уверен, что в виртуальную машину Dart вложено гораздо меньше времени. Поэтому у второй возможно есть достаточно больший потенциал для оптимизаций перед V8
Комментарии (38)
rfq
03.01.2019 13:22«в оптимизацию работы V8 вложено колоссальное количество человеко-часов „
Создатель V8 Lars Bak работает на Гугл с 2004 года, так что команде Dart не надо было изобретать велосипед и вкладывать в Dart столько же усилий, как в V8.
А бенчмарки это дело такое, все они меряют что-то свое. Если мерить задержку и пропускную способность асинхронной обработки сетевых запросов, то Dart заметно быстрее — mrekucci.blogspot.com/2014/09/asynchronous-io-micro-war.html (но Netty все равно лучше).AlexTheLost
03.01.2019 14:18Прикол в том что эти тесты на 500 или боже упаси 1000+ rpc, вычурные, у 99% проектов(это ещё мягкие оценки) такой загрузки не будет. Даже у stackexchange в пике 450 запросов в секунду.) https://stackexchange.com/performance.
Проект скорее упрется в кривую логику и алгоритмическую сложность или в запросы к бд или другие узкие места. А мерять запрос-ответ в вакууме это ни очем, есть ещё куча других моментов.andreylartsev
04.01.2019 12:19Stackexchange при всём уважении, наверное не самый популярный сайт в мире, все же целевая аудитория узковата (и никаких котиков)))). С точки зрения нагрузки надо смотреть на сайты типа google.com, Amazon.com, Facebook.com или отечественные vk.com, mail.ru )
AlexTheLost
04.01.2019 13:59Перечисленное вами как раз попадает в оставшийся один процент. Я хотел донести мысль что тестировать язык или платформу на поглощаемое кол-во запросов секунду это не тот параметр на который нужно обращать внимание. До размеров stackexchange нужно хотя бы дорасти.) А у них нагрузки как видно долеки даже до 500 rps. Там и решения можно применить специфические. А в 99% проблемы будут в других частях.
Karloid
04.01.2019 14:48Собственные бенчмарки это конечно весело, но можно посмотреть\законтрибьютить в www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext&l=zih7jz-1
ogregor Автор
05.01.2019 01:10У многих проггеров страсть к велосипедам собранным ими самими. Я с этим борюсь, но не всегда получается. Плюс это возможность изучить новый инструментарий. K6.io мне подкинул интересную идею, о том что в качестве фронта для программиста может быть использован JS а бека Go, решение получилось очень производительным.
vn_sten
04.01.2019 16:51+1Интересно. Было бы еще интересно взглянуть на сравнения с php+веб сервер и golang
ogregor Автор
04.01.2019 16:52На а этот счёт есть статья от ребят из mail.ru мы же можем сделать вывод относительно Node.js. Golang естественно будет наиболее производительней. На стороне бека я бы за него топил. Но толко в там где появляются узкие места (привет микросервисная архитектура), так как простой прокси на СУБД можно реализовывать на чем то попроще
humbug
04.01.2019 20:17+2А вы читали, как ребята из mail.ru опозорились в своих бенчмарках?
ogregor Автор
04.01.2019 18:04Интересно. Но если разбираться до конца то важно учитывать не только производительность. Для меня важным является то сколько потребляет процесс ( в случае node и Go эта разница составляет 10 раз),
Плюс это наличие библиотек. К примеру недавно уперлись в то что либа под Go не может стилизовать графики Excel. Не знаю как под node но нам пришлось или отказать заказчику в этом требовании или после формирования отчёта, его распаковывать и ручками по регулярке править xml. Вобщем запрос висит на хабе (расширение либы) но из за нас никто это делать не будет, да и мы не хотим тратить на решение этой задачи месяц работы
springimport
04.01.2019 18:08Уточните какой i7. Ведь 2600k в ~3 раза слабее 8700k.
ogregor Автор
04.01.2019 18:55Затрудняюсь, я уже там не работаю. Хотя в статье есть пометка, что тест относительный. Поэтому никакой разницы, что за проц нет. Шина и проц перегружены тестовым фреймворком который запускает по 500-750 http соединений единомоментно
youlose
04.01.2019 19:31У 8700k в 1.5 раза больше ядер(6 против 4), и по тестам он в среднем процентов на 30% (на треть, не в три раза) быстрее. Может быть поделитесь в каких задачах он в 3 раза быстрее?
springimport
04.01.2019 19:44Intel Core i7-2600K vs. Intel Core i7-8700K
Cinebench R15 (Single-Core)
128 (62%) vs 208 (100%)
Cinebench R15 (Multi-Core)
612 (42%) vs 1447 (100%)
В однопотоке разница на треть да, в многопотоке в 2.3 раза. Это не учитывая разгона, в нем однопоток становится быстрее в ~1.7 раз, многопоток в 2.7.
bvbr
04.01.2019 18:30Во первых разгонять сервера как-то не принято.
Во вторых 3х раз все равно нет.
В третьих рендер в сайнбенче — сугубо расчетная задача нагружающая только цпу, а вебсервер в основном занимается вводом-выводом, так сравнивать вообще некорректноspringimport
04.01.2019 18:34Вы читали мое сообщение? Там написан вопрос про модель i7. Какие еще сервера?
3 раз нет, есть почти 3 раза.
Тестировал я как-то приложение на процессоре 2.4ггц и 3.6. Разница была видна даже на глаз. Поэтому частота очень решает.bvbr
04.01.2019 19:07Конечно прочитал,
Сервера при том что обсуждается серверное программное обеспечение,
разница между производительностью i7 первого и последнего поколения относительно не большая, и становится «в разы» только там, где софт может эффективно использовать добавившиеся ядра или новые наборы инструкций, что в случае веб-сервера актуально далеко не всегда
вам примерно об этом написали в 2х комментариях, а Вы зачем-то начали приводить результаты сайнбенча и разгон, хотя это в данном случае не релевантно.
springimport
04.01.2019 19:26Мне вообще была интересна модель i7. Вы опять начинаете про сервера.
Между первым i7 и последним — пропасть. Причем в однопотоке и многопотоке.
Вы видимо думаете что главное чем отличаются процессоры — количеством ядер, но нет. В первую очередь их отличает качество ядер.bvbr
04.01.2019 19:28Сможете эту «пропасть» охарактеризовать в числах?
springimport
04.01.2019 20:09Пару сравнений:
Заголовок спойлера
www.ixbt.com/platform/intel-core-i7-880-8700k.html
www.guru3d.com/index.php?ct=articles&action=file&id=38989&admin=0a8fcaad6b03da6a6895d1ada2e171002a287bc1bvbr
04.01.2019 21:48И? Где пропасть то? (реальная пропасть есть, но она отнюдь не в производительности)
прогресс примерно в 2 раза за 8 поколений и почти 9 лет,
а значимые скачки, как и написал выше, или кол-во ядер или новые инструкции.
если еще нормировать на частоту, то прогресс на каждом поколении придется под микроскопом искать
Напомню, мы с вами в топике бенчмарка http сервера, для которого «числодробительная» мощь проца — далеко не на первых местах по важности, и сравниваются 2 разные программы, а не разное железо
а если уж совсем отойти от темы и по сравнивать теплое с мягким
то можете оценить прогресс от первого до предпоследнего поколения Core в вот этом видео www.youtube.com/watch?v=Viq1bSJHyAM
springimport
04.01.2019 22:04На безрыбье и рак — рыба. Процессоры могли бы расти как видеокарты, но видимо что-то мешает этому. Вы видимо сравниваете с таким ростом, желая роста 100% в год))
В реальности разница в 10% в однопотоке — уже супер, не говоря уже о 100%. Более того, выпусти интел завтра i7-9900k-v2 с 6ггц, фанаты его раскупят даже за $1000 потому что 10% в процессорах = 100% в видеокартах.
Что до многопоточности, Интел без конкуренции придерживала ядра, сейчас же прогресс возобновился. Если амд 9 числа анонсирует 12/16 ядер (я сомневаюсь в этом, но все же), то старые i7 станут сегодняшними пеньками.bvbr
04.01.2019 22:41Вы видимо сравниваете с таким ростом, желая роста 100% в год))
Я пишу о том что ваши «3 раза» далеки от реальности и в данном топике вообще бессмысленны
10% в процессорах = 100% в видеокартах.
тоже крайне спорное утверждение
разница в 10% в однопотоке — уже супер
— с этим соглашусь
серьезных подвижек без смены архитектуры мы пока не увидимspringimport
04.01.2019 23:10Интересно тогда услышать правильный ответ. Во сколько раз быстрее первой модели последняя?
bvbr
05.01.2019 00:30а правильного ответа нет)))
результат будет зависеть от того что мерить, как мерить, где в данных условиях узкое место и еще множества других факторов.
цифра в N раз тоже вполне реальна в том же многопоточном сайнбенче, но абсолютно ничего незначит для других приложений, который не могут так хорошо распараллеливаться по ядрам.
Задействование AES-NI может заставить хилый Atom быть в разы производительней на операциях шифрования по сравнению с гораздо более мощными CPU где AES-NI отсутствует или не включен
AVX может ускорять работу с видео потоками
сам вопросВо сколько раз быстрее первой модели последняя?
не имеет смысла без уточнений при каких условиях.
firedragon
05.01.2019 08:45Поддержу вас. У меня трудится рабочая станция HP Z420. Каких то глобальных различий не видно. Самое смешное что я специально заменил xeon e5 1620 -> xeon e5 2680 v2 нужно было больше ядер для виртуалок.
springimport
Мегагерцы не решают. Подбирайте сбалансированную конфигурацию и будет вам счастье.
jevius
> Dart
Очередное не нужное УГ.
ogregor Автор
Я пробовал Flutter, по производительности он рвет React Native в клочья. Так что у Dart есть определённые перспективы.
jevius
Зачем улучшать то (RN), чего изначально не должно было существовать?
ogregor Автор
Затем что доля заказов на кросплатформу растёт. А RN это боль. Поэтому надо заказчиков мягко переключить на Flutter.
Если рассматривать в контексте веб-сервера. То скорее всего для того чтобы исключить TS, Flow, транспиляцию, и использовать строготипизированый нативно язык на архитектуре неблокирующего эвент лупа
jevius
Это не вопрос, а претензия к фреймворку.
Цукерберг — бизнесмен в первую очередь. Он делает все для оптимизации бизнеса. Но это не значит что он делает правильные вещи.
P. S.: редактировать комментарии искажая изначальный смысл — не надо так. Дописали бы через UPD.
UPD: кроссплатформа на мобильных точно не нужна. Это даже не обсуждается. Точка.
ogregor Автор
Спасибо за замечание. Учту.
На сколько я знаю, в последнее время ходят слухи об ос Фуксия, которая на Dart и Flutter, если это так и она взлетит как приёмница Android, то это уже будет стандарт под мобилы, по крайней мере от Google. Я вот сани летом готовлю.
UDP: А если он (Flutter) ещё и будет из коробки поддерживать портирование под Яблоко, Линукс и Винду, то я лично рад буду только и скорее всего со мной будут радоваться ещё много тысяч заказчиков, которые оплачивают весь этот праздник жизни
jevius
Вы видели приложение Яндекс Карт? Оно на RN. И оно ужасно
Портировать Java код под iOS можно и сейчас, например (см. J2ObjC).
ogregor Автор
— Вы почитайте про Flutter, он предлагает готовые библиотеки компонентов Material Design и Cupertino. Практически пиксель перфект и физикой оригинала
— Основная проблема RN это bridge из за чего возникают проблемы с производительностью при чехарде данными между js движком и нативом, Flutter устроен иначе. Поставщики предлагают 100% аналоги UI при рендере на стороне фреймворка.
— В последнее время стало выходить много интересных приложений от исследователей Flutter и я был поражён его гибкостью. «Всё что угодно» — это можно назвать так.
— Писать в 2019 году на Objective C уже не кашерно
Karloid
> Поставщики предлагают 100% аналоги UI
утверждение которое вводит в заблуждение.
в флаттере не 100% аналоги виджетов UI, к примеру в ios клавиатура уходит вместе с VC в NavigationController, в флаттере нет.
Насчет 100% замены iOS блюров тоже терзают сильные сомнения, беглым поиском не iOS приложения/демо с блюром что бы сравнить с нативным.
(если там тоже самое что и в андроидовском демо с cupertino, то это ужас и кошмар)
ogregor Автор
Да, иногда Остапа сильно несёт. Но в любом случае, судя по тому как это реализуется, то тут вопрос больше в количестве времени которое могут выделить разработчикам на приведение UI в соответствие нативу
D01
Кому не нужно это, если только Вам? Я пишу на Ionic и это востребовано.
shandy
А если сравнить с NativeScript? У него другой механизм, чем у RN.