Всегда ли Node.js будет медленнее, чем Golang?

Автор оригинала: Alex Hultman
  • Перевод
Возникает такое ощущение, что буквально каждую неделю появляется новый «веб-фреймворк» для Node.js, который называют чем-то таким, что работает быстрее, чем всё, что было до него. Всем известно, что Express — это медленно, но способен ли очередной фреймворк по-настоящему улучшить производительность подсистемы ввода-вывода Node.js? Единственное, что он может — это устранить чрезмерную нагрузку на систему, создаваемую Express. Об улучшении чего-то фундаментального речи не идёт. Собственно говоря, для того, чтобы кардинальным образом улучшить ситуацию, нужно работать на более глубоком уровне, а не добавлять новые абстракции поверх Node.js.

image

Что нужно для того, чтобы на платформе Node.js можно было бы создавать серверные приложения, работающие гораздо быстрее чем всё то, что есть сегодня?

Анализ ситуации


Express — один из старейших веб-фреймворков для Node.js. Он основан на стандартных возможностях этой платформы, давая разработчикам удобный интерфейс, построенный вокруг концепции приложения, и позволяя управлять URL-маршрутами, параметрами, методами и прочим подобным.

Express прост, он помогает программистам быстро разрабатывать приложения. Единственное, чего ему не хватает — это производительность. Постоянно появляющиеся проекты, вроде Fastify, стремятся к тому, чтобы дать разработчикам те же возможности, что и Express, но с меньшими потерями производительности. Но они сами являются тем, что создаёт дополнительную нагрузку на систему и плохо влияют на производительность. Они жёстко ограничены тем, что может дать платформа Node.js. А дать она, в сравнении с конкурентами, может не так уж и много.


Количество HTTP-запросов, обрабатываемых разными серверами в секунду

Обратите внимание на красную линию. Это — максимум платформы Node.js. Фреймворки для неё, независимо от того, есть ли в их названиях слово «fast» или нет, эту линию пересечь не в состоянии. На самом деле это — очень низкий предел производительности, если сравнивать платформу Node.js с её популярными альтернативами наподобие Golang.

К счастью Node.js поддерживает C++-аддоны, биндинги Google V8, которые позволяют связывать JavaScript и C++, и позволяют вызывать из JavaScript любые механизмы, даже в том случае, если эти механизмы предоставляются чем-то, отличающимся от платформы Node.js.

Это делает возможным расширение и улучшение возможностей JavaScript-приложений, позволяет выйти на новые уровни производительности. Это позволяет JavaScript-программам выжать всё возможное из движка Google V8, не ограничиваясь тем, что разработчики Node.js сочли вполне достаточным.

О выходе µWebSockets.js


В начале этого месяца я выпустил новый проект — µWebSockets.js. В качестве хостинга для его кода используется GitHub, а не npm, но установить его для Node.js средствами npm можно так:

npm install uNetworking/uWebSockets.js#v15.0.0

Для работы с µWebSockets.js не нужен компилятор. Поддерживаются Linux, macOS и Windows. Исходной версией системы является 15.0.0, нумерация версий осуществляется по правилам семантического версионирования.

µWebSockets.js — это альтернативный веб-сервер для бэкенд-приложений, написанных на JS. Он состоит из примерно 6 тысяч строк C и C++-кода и значительно обходит по производительности лучшие решения, написанные на Golang. Так, биржа bitfinex.com уже портировала оба своих торговых API (REST и WebSocket) на µWebSockets.js и постепенно вводит их в продакшн. Паоло Ардоино из Bitfinex отмечает, что это — замечательный проект. Мне же хотелось бы сказать, что тому, что у меня появилась возможность выпустить µWebSockets.js, я всецело обязан поддержке, оказанной мне BitMEX, Bitfinex и Coinbase.

Особенности µWebSockets.js


µWebSockets.js — это новый проект, выпущенный под лицензией Apache 2.0, который является продолжением того, что известно как «uws». Данный проект представляет собой полный стек для Google V8, начинающийся на уровне ядра операционной системы, полностью заменяющий стандартные возможности Node.js и представляющий собой стабильную, безопасную, соответствующую стандартам, быструю и легковесную подсистему ввода-вывода для Node.js. Вот как выглядит взаимодействие JS-приложения с операционной системой с применением µWebSockets.js.


Взаимодействие JS-приложения с ОС c применением µWebSockets.js

Как видите, проект состоит из нескольких слоёв. Каждый слой зависит лишь от предыдущего слоя. Такая архитектура упрощает выявление и исправление ошибок, а также выполнение работ по расширению решения за счёт реализации в нём новых возможностей.

Надо отметить, что слой µSockets сам состоит из трёх подслоёв, представляющих собой механизмы для работы с событиями и с сетью, а также инструменты для защиты данных. Это позволяет, при необходимости, заменять части решения, добавлять в систему альтернативные реализации тех или иных возможностей, не сталкиваясь при этом с необходимостью изменения кода, находящегося на более высоком уровне.

Например, если нужно заменить на что-нибудь OpenSSL, для этого достаточно поменять на то, что нужно, файл ssl.c с его шестью сотнями строк кода. При этом другие слои системы даже не знают о том, что такое SSL. Такой подход, помимо удобства замены одних частей системы на другие, ведёт и к упрощению процесса обнаружения ошибок.


Внутренние подслои µSockets

Представленная здесь архитектура серьёзно отличается от той, монолитной, которая используется в Node.js, где в одном и том же файле исходного кода можно встретить и вызовы libuv, и команды для работы с системой, и обращения к OpenSSL и V8. В Node.js всё это смешано, никто не задавался целью изолировать отдельные части этой платформы. Это значительно усложняет процесс внесения серьёзных изменений в Node.js.

О разработке для µWebSockets.js


Вот чрезвычайно упрощённый и сокращённый пример работы с µWebSockets.js, главная задача которого — продемонстрировать базовые возможности системы.

/* SSL-приложение с маршрутами */
uWS.SSLApp({
    key_file_name: 'misc/key.pem',
    cert_file_name: 'misc/cert.pem',
    passphrase: '1234'
}).get('/hello', (res, req) => {
    /* Очень сильно упрощено */
    res.end('Hello World!');
}).ws('/*', {
    open: (ws, req) => {
        console.log('A WebSocket connected via URL: ' + req.getUrl() + '!');
    },
    message: (ws, message, isBinary) => {
        /* OK имеет значение false при переполнении
         * рекомендовано дождаться сброса буфера */
        let ok = ws.send(message, isBinary);
    },
    drain: (ws) => {
        console.log('WebSocket backpressure: ' + ws.getBufferedAmount());
    },
    close: (ws, code, message) => {
        console.log('WebSocket closed');
    }
}).listen(port, (token) => {
    if (token) {
        console.log('Listening to port ' + port);
    }
});

В определённом смысле, можно говорить о том, что µWebSockets.js с применением SSL может обойти Gorilla WebSocket, реализацию протокола WebSocket на Go, без SSL. То есть оказывается, что JS-код может обмениваться сообщениями с использованием SSL даже быстрее, чем, при определённых условиях, код, написанный на Go без SSL. Полагаю, что это — отличный результат.

Быстрая реализация протокола WebSocket


Socket.IO, во многих отношениях, можно считать эквивалентом Express, работающим в режиме реального времени. Оба эти проекта появились достаточно давно, работать с ними просто, они пользуются популярностью. Но они, кроме прочего, ещё и медленны.


Различные реализации WebSocket

Задачи, которые помогает решить разработчику Socket.IO, сводятся к реализации функционала публикации сообщений и подписки на них, к возможностям отправки и получения сообщений.

При этом надо отметить бесполезность использования неких запасных механизмов для работы с протоколом WebSocket, так как браузеры уже давно поддерживают эту технологию. SSL-трафик не может интерпретироваться корпоративными прокси-серверами, он проходит через них точно так же, как проходит любой HTTP-трафик, в результате использование протокола WebSocket поверх SSL не приводит к блокировке соответствующего трафика. Запасные механизмы для поддержки WebSocket предусмотреть можно, но в их использовании нет никакого смысла. Они лишь неоправданно увеличивают сложность решений.

Одна из целей µWebSockets.js заключается в том, чтобы дать разработчикам возможности, похожие на те, которые есть в Socket.IO, для того, чтобы µWebSockets.js мог бы полностью заменить Socket.IO без необходимости использования каких-либо обёрток более высокого уровня. Это возможно в том случае, если не используется какой-нибудь особенный нестандартный протокол.

Многие компании сталкиваются с проблемами публикации сообщений и подписки на них при работе с WebSocket. Надо отметить, что в описываемом релизе µWebSockets.js этим возможностям не было уделено особенного внимания, но сейчас над ними ведётся серьёзная работа. То, что получится в результате, будет очень быстрым (тесты показывают, что µWebSockets.js уже оказывается быстрее Redis). Поэтому следите за новостями.

Итоги


В настоящее время µWebSockets.js развивается, в проект добавляются новые возможности, исправляются ошибки. Некоторое время уйдёт на то, чтобы избавиться от тех мелких недостатков, которых характерны для первых релизов новых программ. Учитывайте то, что речь идёт о большом проекте, состоящем из многих тысяч строк кода, написанного на C и C++, который хранится в трёх репозиториях. Здесь лежит JavaScript-обёртка — uWebSockets.js. Вот веб-сервер, написанный на C++ — uWebSockets. А вот — базовая библиотека, написанная на C — uSockets.

Проект, о котором идёт речь, используется компаниями, программы, применяемые которыми, создают огромную нагрузку на подсистемы ввода-вывода. В этих компаниях стабильность и безопасность, что совершенно естественно и очевидно, являются важнейшими характеристиками используемого ими ПО.

Уважаемые читатели! Планируете ли вы использовать µWebSockets.js в своих проектах?

RUVDS.com
971,01
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Комментарии 116

    +4
    Отличная новость, спасибо и писать так же на JS можно, а то слишком много языков появляется с неопределенным будущим и всех их изучать как-то не очень хочется, время не резиновое к сожалению.
      –2
      Достаточно выучить один из мэйнстримных сейчас (C++, C#, Java, Python и т.п.) и работой на ближайшие 10-15 лет вы точно будете обеспечены. А вот люди условно выучившие js и пытающиеся с его помощью реализовывать всё подряд от серверов до мобильных приложений кажутся тем самым чудаком с молотком, которому всё вокруг кажется гвоздями; и, как результат, порождают горы некачественного софта с коротким временем жизни.
        +10
        По-вашему JavaScript это не мейнстримный язык? octoverse.github.com/projects#languages
        Тот факт что вам что-то чем-то кажется не означает что это так.
          –1
          JS — замечательный мейнстримный язык для работы с web-страницами, но пытаться использовать один инструмент для любых целей, как минимум — не дальновидно.
          Кроме того, в случае с js, я не уверен что будет выполняться условие работой на ближайшие 10-15 лет вы точно будете обеспечены ибо уже сейчас количество выброшенных на рынок js разработчиков намного выше чем в любом другом языке и, в силу простоты и популярности языка, их количество только растёт, так что есть шанс что предложение превысит таки спрос.
            +8
            Извините, но ваша аналитика не подкреплена фактами, а строится на субъективном негативе к JS.

            Вы действительно полагаете что JS в плане будущего трудоустройства хуже чем C++ или C#? Это абсурд. Объективно области применения JS шире (с точки зрения рынка труда) чем у этих двух языков. У них так же есть негативные факторы, как то сужающаяся ниша у C++ и появление конкуренции, так и вендор-лок у C#.

            Почему-то ваши претензии к JS вы не применяете к Java. Её тоже пытались использовать для всего (и сейчас кстати много для чего используют и пытаются использовать в той же манере). И точно так же у неё огромная популярность, хотя про порог входа ничего не могу сказать.
              +4
              а строится на субъективном негативе к JS.

              Эм, да. И что? Человек пожаловался на невозможность выучить все существующие нынче языки программирования, я предположил что все учить и не нужно, достаточно одного, но хорошо выученного.
              Если вы хотите писать приложения под мобилки учите java, десктопный софт C++/C# и т.д.
              ИМХО лучше хорошо знать язык подходящий под вашу область интересов, чем пытаться один и тот же язык натянуть на все области программирования сразу. Всё равно объём труда и сил затраченный на получение экспертных знаний даже в одной области много больше чем объём необходимый на изучение плюс/минус одного языка.
              И если в каком-то языке есть инструментарий позволяющий качественно решить какую-либо задачу не лучше ли воспользоваться этим инструментарием, чем ждать появления подобного под js?
              И да, субъективный негатив к js вполне может у меня быть, я никогда не претендовал на роль беспристрастного эксперта. Но наблюдать как на сайтах становятся нормой бандлы по мегабайту кода, а на десктопы приходит тормозной софт на электроне и иже с ним, несколько утомляет. Эти люди вполне могли потратить свои силы и талант на разработку куда более совершенных решений. А в итоге куча сил уходит в разработку писаного на коленке кода, который приносит доход вотпрямща, в ущерб моему железу и времени. Да, таки эта ситуация вызывает во мне негативный отклик и советовать людям учить js я не могу, как бы хорош он ни был.
                +2
                Бизнес с вами не согласен, для бизнеса сервер + клиент + мобильное приложение + десктопное приложение только на жс это золотая жила. И им плевать на то сколько вы языков знаете если вашу команду можно заменить одним человеком :) Так что нет, на жс спрос не падает пока, и скорее всего не будет
                  +1
                  И им плевать на то сколько вы языков знаете если вашу команду можно заменить одним человеком

                  Если команду из 5 человек заменить одним универсалом, то скорость разработки упадет в 5 раз даже если инструмент позволяет так же эффективно решать задачу, а обычно это не так.

                  Нанимать же 10 универсалов вместо 5 специалистов это уже более интересный размен. Бизнес как-то додумался, что вместо фуллстеков лучше разделять бек и фронт. И что девопса лучше отдельного нанять, а не требовать от разработчиков среду конфигурировать. Зачем вы предлагаете двигаться в обратном направлении? Не представляю.
                    0
                    Да, я неправильно выразился и перефразирую:
                    Есть у нас бек, фронт, и мобильное приложение
                    для этого надо 4 разные команды узких специалистов, или одну команду специалистов на жс.
                    Вторые будут выгодней с точки зрения бизнеса, ибо могут подменять друг друга и обучаться вместе при надобности, да, они (возможно) будут хуже знать свое дело чем того же уровня узкий специалист, но в большинстве случаев не нужно идеально знать инструмент.
                      0
                      Я же ответил, вы не меняете 4 специалиста на 4 универсала. Для того же эффекта вам их нужно штук 8, потому что JS по-определению будет менее эффективный, чем специально заточенный инструмент.

                      И вот будут ли 8 универсалов дешевле 4 специалистов — вопрос.
                        0
                        Почему же штук 8? Вы оперируете странными терминами. Если жс менее эффективный, значит надо больше лудей? В большинстве задач рынка не нужно идеальных людей, не нужно идеальных инструментов и не нужно идеальных решений. Нужны продукты которые делают определенную задачу. И в большинстве задач жс может заменить другой язык 1 к 1. Не везде, не всегда, иногда при некоторых обстоятельствах, но в большинстве задач рынка может. Сейчас даже нейронные сети можно обучать на жс.
                          +1
                          нейронные сети можно обучать на жс

                          Их хоть на брейнфаке обучать можно. Только никому это всерьёз не нужно. Сколько у вас будет обучаться сеть на js? Пару веков? А все «взрослые» нейросети по факту на C/C++ с пробросом хвостов в другие языки для упрощения использования.
                          Почему же штук 8? Вы оперируете странными терминами. Если жс менее эффективный, значит надо больше лудей?

                          Потому же почему 9 женщин не смогут родить ребёнка за месяц. То что вы напишете один код ко всем платформам не избавит от необходимости его тестировать на каждой отдельно и учитывать все специфики при написании.
                            0
                            И в большинстве задач жс может заменить другой язык 1 к 1.

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

                            В итоге на последних моих двух работах мы пользуемся для внутренней переписки исключительно телеграм, просто потому что он не тормозит. Вот вам и «неидеальный» слак. Причем, я так думаю, оптимизировать там особо нечего с прикладной стороны, это сам электрон такой.
                              0
                              Вы кстати привели прекрасный пример приложения на жс, команда разработки которого заменяет 4, туда же в копилку и скайп.
                              По поводу тормозов на медленном инете спорное заявление, вы думаете жс требует больше данных от апи для работы при условии что все загружено (привет PWA) и закешировано? Слак тупит по другим причинам :) Зато кодовая база у них одна на несколько платформ, что очень сильно уменьшает время разработки, а значит сильно экономит деньги, а значит более плагоприятно для держателей бизнеса, и значит добавляет быстрей и больше фич и удобства пользователям.
                              Безусловно есть варианты где натив лучше, но это не частое требование, но всегда более дорогое, иногда на порядок дороже.
                    0
                    Извините, но вы под дулом пистолета устанавливаете софт или открываете сайты с «по мегабайту кода»?
                      0
                      Эм, да?
                      Есть софт выбор которого определяется корпоративными стандартами и количеством людей в нём сидящих. Если нужно работать в обществе от него никуда не денешься.
                        0
                        Ну да. Если вас не устраивает софт который был определён корпоративными стандартами, ты вы точно так же можете поменять компании чьи стандарты вас не устраивают. Или на работе вы сидите под дулом пистолета?

                        То есть я понимаю что вы имеете ввиду поднимая тему не удобности софта. Но не понимаю почему вас это действительно так задевает и вы ничего не делаете что бы облегчить себе моральные страдания. Мыши плакали, кололись, но продолжали грызть кактус?

                        Вы свободный человек, только вам решать что использовать и с чем работать.
                  +3
                  Может, выкидывают совсем бездарей? Попробуйте в Москве найти сеньора на JS (который, естественно, + React, Anular, Vue, Node и всё вот это)
                    +3
                    Понятное дело, что бездарей. Но не совсем, т.е. приложеньку которая работает они пишут, заказчику этого хватает. А вот задачи написать хорошо работающую приложеньку, обычно не стоит.
                    React, Anular, Vue, Node и всё вот это

                    добавьте туда react-native и electron до кучи уже. Только зачем вам этот человек-комбаин который типа знает всё? Сказать что ты хорошо знаешь и владеешь какой-то технологией можно, думаю, через год-два плотной работы с ней. Если у вас синьёр одновременно отлично знает все существующие js фреймворки то либо ему 100 лет, либо он 3,14дит.
                      0
                      Это просто требования рынка. Вот я сейчас будут пилить свой проект-хомяк на Angular2++, просто для резюме. На работе React+Node
                        0
                        А как насчёт варианта «принципиальных отличий между фреймворками немного, зная хорошо один, можно быстро переучиться на другой»?
                          0
                          Быстро это сколько в баксах? Работодатель вон ищет
                          сеньора на JS (который, естественно, + React, Anular, Vue, Node и всё вот это)

                          который сразу сеньор, а не переучится. Работодатель будет оплачивать время переучивания?)
                          Типа зная Vue, вы за несколько часов запустите какой-нибудь hello-world на ангуляре. Но на то чтоб разобраться в существующих решениях/модулях и выбрать из них лучшие для себя уйдут опять же годы, не?
                          Так то зная js можно быстро переучиться на rust, ага. Паттерны в принципе такая штука которая кочует от языка к языку, а вот тот дьявол, который кроется в деталях познаётся только в процессе работы имхо.
                            +2
                            Если вы отлично знаете сам js, то чтобы перейти с одного фреймоврка на другой вам не нужны годы
                              0
                              отлично знаете сам js

                              Что конкретно вы подразумеваете под «сам js»? Сотню операторов? Десяток api разных браузеров? Паттерны? Общепринятые подходы и методы? Чего там запоминать и «знать»-то?
                              Знание языка никак не избавляет от необходимости глубокого понимания области применения.
                              Для того чтоб «перейти» да, достаточно нескольких часов, я написал.
                              Для того чтоб начать писать чистый код на уровне синьора в соответствии с идеологией конкретного фреймворка нужно гораздо больше времени.
                                +2
                                не годы, поверьте. Есть реальные примеры, когда знакомые работали на позиции сеньора в проекте на angular и переходили на проект с react. Им хватало месяца, чтобы погрузится и писать на сеньорском уровне. Какие-то слишком специфичные вещи и подводные камни в любом случае решаются по мере возникновения реальных задач и проблем, но это не означает что вы плохо владеете фреймворком
                                  0
                                  Скорее, если имеешь опыт применения JS в современной среде разработки, то, скорее всего, быстро перейдёшь на новый фреймворк.

                                  ps. Мне тут очередная девочка-хрюша прислала вакансию, требования — Angalar 6 опыт от года. Я ей ответил, что он вообще вышел в прод в мае 2018. Что-то не пожелала продолжить диалог
                                    +2
                                    Что конкретно вы подразумеваете под «сам js»? Сотню операторов?? Десяток api разных браузеров? Паттерны? Общепринятые подходы и методы? Чего там запоминать и «знать»-то?

                                    Подходы и паттерны как раз. Большинство веб-фрейморков все равно делают одинаковые вещи, биндинг (одно-двухсторонний), реактивное программирование, деление на компоненты и прочее.

                        0
                        Показатели гитхаб не очень верно расматривать в абсолютных значениях. Вот научная статья, которая разбирала сколько дубликатов на гитхабе по разным языкам программирования:
                        blog.acolyer.org/2017/11/20/dejavu-a-map-of-code-duplicates-on-github
                        Интересно почитать всю статью, но краткая выдержка такая:
                        у JavaScript 261 миллиона файлов, из которых только 6%(всего 16 миллионов файлов) не дубликаты.
                        У той же Java не дубликатов 60 % или 43 миллиона файлов.

                        Так что скорее можно назвать JavaScript лидиром по копи-пасту.
                        +1
                        Хочу заметить что JS тоже мэйнстрим!
                          +2
                          Хочу заметить, что я не утверждал обратного!
                          0
                          Одно знание языка программирования работой не обеспечивает. Современное программирование — это, в первую очередь, знание библиотек, фреймворков, технологий. А язык программирования — просто инструмент.

                          В случае JS экосистема меняется очень быстро. Каждый год-два приходится переучиваться под новый фреймворк. Если этого постоянно не делать, то ценность программиста будет снижаться.
                            0
                            Каждый год-два приходится переучиваться под новый фреймворк
                            Современный стек в топе уже года четыре минимум. И пока не видно ему альтернатив.
                              +2
                              4 года назад был другим и язык (ES5, CoffeeScript), были другие иинструменты сборки (gulp), популярными были другие фреймворки (Backbone, AngularJS).
                                +3
                                4 года назад уж был и ES6, и Webpack, и React, и TypeScript/Flow, и даже Redux.
                                Я помню, потому что в конце 2015-ого менял работу и тогда уже на каждом собеседовании спрашивали про разницу между Реактом и Ангуларом, про то, зачем нужен Редакс, когда пользоваться props, а когда — state.

                                Вот, к примеру, статья четытерхлетней давности о том, почему нужно использовать ES6 и где использование Вебпака описывается как само собой разумеющееся:

                                Типичный сценарий, чтобы проиллюстрировать эти недостатки это генерация связки модулей для браузера, с помощью таких инструментов, как browserify или webpack


                                Хотя о нем на Хабре писали еще в 2014-м и, судя, по комментариям, никто особо не удивлялся, как Редаксу в 2015-ом.

                                О том, какой будет Angular 2 и то, что он будет на Тайпскрипте было ясно точно так же в 2015. Да, популярности Вью не 4, а три года, но он сейчас не обязательный.

                                Ну и самое главное — пока не видно, чтобы это был закат всех этих фреймворков. Минимум года два они еще точно будут активно использоваться и тогда, через два года может какой-то другой фреймворк на собеседованиях станет обязательным. Но цикл явно не год-два, как сказали ранее.
                                +1
                                Добавился redux, вторая ветка Angular, стал мастхэв TS и фишки ES6/7/etc
                                  0
                                  Ответил выше
                              +1

                              1) Js, пожалуй единственный язык который позволяет реализовать полностью весь стек ИТ систем. Фронтенд, бекенд, мобильные и десктопные приложения. Простыми словами, владея Js вы можете создать полностью законченное решение.
                              2) Я работал фуллстек программистом, писал на C#, Golang, JS. Но решил выбрать специализацию фронтенд, и в том числе по причине того, что фронтенд программистам платят не меньше и зачастую больше. И к тому же вакансий больше.

                                0
                                Delphi позволяет делать делать весь спектр. Веб за счет траннспилляции pas > js, либо биндов к ExtJS. Однако вся разработка может вестись в Delphi. Остальные платформы — нативно работают.
                                  +2

                                  Основной вопрос в том, какого качества получается этот "весь стэк". Сравните телеграм и слак для Андроид. Разница не то, что очевидна, слака прям плакать хочется. А альтернативы нет, поскольку корпоративный мессенджер. На том и играют. А пользователи страдают. По мне, так лучше качественный софт, чем тормознутый монстр

                                    0
                                    У нас Slack вполне справляется с возложенными на него функциями
                                      0

                                      "Вполне справляется" и "приятно пользоваться" — это разные вещи. У нас тоже справляется, но если у меня есть возможность лишний раз не запускать его на мобильнике, я с облегчением не буду этого делать. В отличие от того же телеграмма, когда там и запуск быстрее, и интерфейс намного отзывчивее и выглядит не как веб страница, и текст можно выделить и скопировать частями, а не все сообщение без возможности выделения.

                              +3
                              понятно, что автор унаследовал название от плюсовой либы, но все равно как странно называть WebSokets реализацию http-сервера, пусть и с web-socket на борту
                                0

                                Запрос на хендшейк посылается по HTTP, с заголовком на переключение протокола.
                                Ну то есть можно было-бы условно захардкодить этот момент, а можно было и подрубить полноценную обработку HTTP. Авторы видимо выбрали последний вариант.

                                +5
                                У меня одного аллергия на букву µ? Её же не набрать на клавиатуре, не найти быстро в поиске по первому символу, не найти в папке с файлами, начиная быстро набирать первую u, которая не µ. Неужели настолько принципиально называть проекты с неписуемымт буквами? Вон в npm то он засунул его более менее user-friendly: uwebsockets. А если бы наши программисты все названия пакетов на кириллице писали? Какой ад тогда был бы у всех остальных…
                                  –5
                                  Её же не набрать на клавиатуре

                                  Alt + 0181
                                    +3
                                    Есть более чем одна операционная система.
                                    +3
                                    Хм, я, похоже, зря назвал одну из либ, которую сейчас пилю, как ℤ.
                                      +5
                                      И это вы еще не видели китайский C++ :D

                                      image
                                        +1
                                        Чёт смешно. Хорошо, что я не китаец.
                                          0
                                          Крутяк! А я ведь учил китайский. Думал даже, буду работать с китайцами :) Но не срослось
                                        +6
                                        А если бы наши программисты все названия пакетов на кириллице писали?


                                        У нас не только названия пакетов пишут кириллицей, у нас целый код порой кириллицей пишут:

                                        image
                                          +1
                                          Да это же просто шедевр!
                                            –1
                                            Пример очень плохой. В 1С традиционно принят PascalCase, а вот это вот «Для каждого… из» вместо «Для Каждого… Из», и «ФамилияСотрудника = Сотрудник.фамилия» вместо Сотрудник.Фамилия — нельзя так писать. Даже на 1С.
                                              +4
                                              То есть если исправить регистр в соответствии с традициями 1С, то пример станет хорошим? :) На счет примера китайского c++, как я понимаю, возражений нет? :D
                                            +1

                                            В npm есть ограничения на имена пакетов (разрешается только латиница и немного пунктуации). Мне кажется, что если бы не это ограничение, то пакет бы тоже назывался µWebsockets.

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              +1
                                              Спасибо за статью, интересный график сравнения nodejs и go, а так же ряд с++ реализаций. Для полноты картины хотелось бы в нем ещё увидеть Netty, так как в некоторых статьях попадаются цифры 100 000 http запросов на ядро.
                                                +9
                                                Это очень неплохо, но с виду само решение — написать высокопроизводительную часть node.js не на node.js отвечает на вопрос в заголовке статьи.
                                                  +2

                                                  Как бы да.


                                                  Приятность того же Go в легком программировании любых конкуррентных задач, а не только HTTP или вебсокетов.


                                                  Тут же на Си реализовали какую то небольшую часть сетевых протоколов и заявили что Node стал быстрее.


                                                  Не стал.

                                                    +1

                                                    И при этом совсем не раскрыта тема, что рулит, по сути, низкоуровневое "ядро". Которое, как я понимаю, при этом ещё и достаточно универсально.
                                                    Завтра сделают биндинг к нему для Go — и всё, тема статьи снова станет неактуальной.

                                                      +3
                                                      > Завтра сделают биндинг к нему для Go — и всё, тема статьи снова станет неактуальной.
                                                      биндингом не решится, в go свой рантайм и вызов сишных функций дороже нативных.
                                                      Только так ли это нужно, если на не свежем i5-4670 net/http из стандартной библиотеки go 1.11 выдает 160k rps.
                                                    +5
                                                    И в итоге рынок вакансий для JS поделится на 2 части: 1) тех, кто умеет просто JS и 2) тех, кто умеет делать привязки к библиотекам на C/C++, может, если что, заглянуть в исходники этих библиотек и что-то подкрутить, или даже написать свою библиотеку на C/C++.
                                                    И это уже происходит с Python и PHP — серьёзные и интересные проекты вдобавок к этим языкам требуют знание Go (иногда C++).

                                                    А сама статья — довольно шаблонный пиар: «Я залез в дебри ядра Linux, скурил всего Майкла Керриска, выучил C как сам Керниган, кучу времени потратил на оптимизации и даже написал несколько ассмеблерных вставок и вот результат: самый быстрый веб-сервер на Python/JS/you-name-it, который умеет 100500 запросов в секунду». Для Python был japronto. Слышал, он сейчас заброшен, говорят, что автор работу так искал.
                                                      +3
                                                      А потом какой-нибудь «программист Педро» берёт этот супербыстрый вебсервер, понапишет всякого блокирующего io, новые коннекты к БД на каждый запрос и т.д. а потом внезапно этот ваш вебсервер тормозное УГ.
                                                      +2
                                                      Если я правильно понял суть статьи, то uwebsocketjs это просто JS биндинг, для быстрой C и C++ реализации http, websocket? От этого код написаный на JS не будет работать быстрее чем на NodeJS. Разве что приложение в целом будет работать быстрее, за счет быстрых системных вызовов.
                                                        +2
                                                        На techempower.com/benchmarks этой штуки пока не видно. Не интересно.
                                                          +7

                                                          А есть разница на реальных проектах? Все равно львиная доля ресурса уйдет на сериализацию/десериализацию json и бизнес логику. Да и на проектах с нагрузкой больше 1к уже инфраструктура состоит не из 1 ядра, и масштабировать придется все равно бизнес логику а не реализацию ws

                                                            +3
                                                            Тоже интересно. Сравнивал Node.JS и Scala, да Scala быстрее в 5 раз на 0-вом ответе. Но как только добавил JSON обработку, скорость упала до одного уровня.
                                                            +1
                                                            Графики вызывают подозрения. На странице с бенчмарками (https://github.com/uNetworking/uWebSockets/tree/master/benchmarks) налито воды на несколько страниц, о том как правильно делать бенчмарки, а в результате в конце: «todo, will be added before release». С каким настройками были протестированы сервера, на каком железе — непонятно…
                                                              0
                                                              Графики вообще бредовые. Я сейчас найти не смогу уже, но в памяти крутится статья тут же на хабре про Nginx, когда он ещё не получил такого развития как сейчас. Там было в примерах показано как его грамотно под хай-лоад настроить. Так вот там он под миллион запросов в секунду обслуживал без проблем. Я чёт не представляю как такое вообще реализовать на языке, который априори крутится в виртуальной машине.
                                                                –1

                                                                Точно так же. Только ресурсов нужно по-больше.

                                                                  0
                                                                  Если ресурсов больше, то и нативные методы работать быстрее будут.
                                                                  0

                                                                  Сейчас в JS почти нигде нет чистых виртуальных машин, почти везде JIT-компиляция, причем часто довольно агрессивно оптимищирующая.

                                                                    –1
                                                                    Ну, если оно в байт-код потом компилируется, тогда ваша правда, конечно, это быстрее гораздо. Только вся технология становится на цирк с конями похожа.
                                                                      0
                                                                      jit не избавит вас от garbage-collector'а. Jit сам по себе тратит ресурсы на компиляцию/сравнение производительности/перекомпиляцию. jit не оптимизирует вам использование памяти и не сможет перетащить переменную неопределённого типа из кучи в стэк.
                                                                      Jit бесспорно помогает значительно увеличить производительность программы. Но в сферическом вакууме интерпретируемый язык с большим рантаймом никогда не догонит низкоуровневые компиллируемые и изначально типизированные языки (да простят меня адепты js, java, питона и иже с ними)
                                                                        0
                                                                        Ну так я об этом писал.
                                                                  0
                                                                  А то что графики «нормализованы по ЦПУ» не смутило?)
                                                                  0

                                                                  Любопытно. А с аналогичным решением на go https://github.com/gobwas/ws пробовали сравнивать?

                                                                    0
                                                                    это чисто вебсокетная либа
                                                                    –2
                                                                    опыт интересный, но зачем?
                                                                    1. Брать сторонюю либу — зависимость от стороннего разработчика.
                                                                    2. Если разбираетесь в с\с++ — есть возможность чтото подпилить\под себя подкрутить
                                                                    3. Если разбираетесь в с\с++ — зачем клеить в nodejs с\с++ и продолжать писать на js?

                                                                    это все как то странно выглядит… утверждение и сравнение в томже числе.
                                                                      0
                                                                      В компании есть спецы по С++, но основная часть пишет на js. Например.
                                                                        0
                                                                        Даже возможно «все пишут на JS, но у одного человека есть опыт с С++»
                                                                      0
                                                                      Я хотел написать длинный комментарий про «от чего зависит скорость программ», но в процессе стало лень.
                                                                      Если мне нужен очень-очень-очень быстрый вебсервер то с подходом автора я бы вообще железку купил, в которой нужный мне протокол будет реализован нативно. Быстрее будет просто некуда.
                                                                      А так автор, как и многие другие, пожертвовал гибкостью и получил скорость. И чего пиарится?
                                                                        +1

                                                                        Когда уже люди прийдут к тому, что меряется rps'ами довольно бестолково?)

                                                                          0
                                                                          Когда юзверей лишат права выбора, чтобы они, вместо того чтоб уйти на другой продукт, будут продолжать пользоваться тормозным поделием.
                                                                          Типа rps'ы сами по себе не особо полезная метрика. Но обычно корреляция между rps и общей «отзывчивостью» приложения таки соблюдается.
                                                                          Между двумя одинаковыми решениями выиграет то, которое будет быстрее работать.
                                                                            +3
                                                                            Между двумя одинаковыми решениями выиграет то, которое будет быстрее работать.

                                                                            То-то все пользуются телеграмом как корпоративным чатом, а не слаком. А нет, черт, все равно наоборот, потому что пользоватся телеграмом как корпоративным чатом невозможно, его ui просто не заточен под это.


                                                                            В реальном мире достаточно, что бы приложение работало приемлемо быстро для пользователя. И стоит учитывать, что существует тысяча и один способ выполнить долгую операцию в фоне, что бы пользователя это все еще оставалось приемлемо быстро. Не говоря уже о том, что в довольно большом количестве случаев время ожидания ответа от той же бд в приложении будет занимать 50-80% времени запроса.

                                                                              0
                                                                              ежа с ужом сравниваем...
                                                                              Я потому и написал одинаковыми. Скорость не определяющий фактор при выборе решения, но и отбрасывать её нельзя.
                                                                              Типа запустите вы слак, insomnia, VSCode, chrome, скайп и привет оперативка. Потом появятся у нас sftp клиенты на электроне, какой-нибудь electon-git, оболочки на js. Пока карман позволяет докупать память вы будете оправдывать эти решения, а потом просто пойдёте искать что-то менее прожорливое.
                                                                              Типа если выйдет аналогичный слаке продукт с нативной поддержкой большинства платформ вы продолжите делать ставку на слак?
                                                                                +2
                                                                                Типа если выйдет аналогичный слаке продукт с нативной поддержкой большинства платформ вы продолжите делать ставку на слак?

                                                                                В реальности такого же не просходит. И не происходит в основном потому что при разработке слака сделали в том числе фокус на фичи и интеграции, пожертвовав производительностью. Разумеется, если будет приложение как слак, но еще и оно будет быстрее работать, я выберу его, а не слак.


                                                                                Но такого выбора мне никто не предоставит, и меряя языки по rps, а не скажем, по "сколько строк (выражений) мне понадобится на реализацию этой бизнес-фичи" вы возносите менее важную метрику.

                                                                                  0
                                                                                  вы возносите менее важную метрику

                                                                                  Для кого менее важную? Для бизнеса и скорости разработки? да, допустим.
                                                                                  А для конечного пользователя и развития индустрии в целом — большой вопрос. Доступный объём памяти и производительность компьютеров в пределе — конечная величина. У нас уже, кажется, не выполняется закон Мура.
                                                                                  Типа ок, сейчас бум электронов и spa, вы наплодите js-разработчиков и чатиков по 200мб. А дальше куда?
                                                                                    +3
                                                                                    конечного пользователя

                                                                                    Отвечу как "конечный пользователь" — да, для конечного пользователя. Если в продукте нет какой-то нужной мне фичи, я им не пользуюсь. Если в продукте она есть, но он приемлемо тупит, то можно попробовать.


                                                                                    И со мной согласны, например, большинство программистов, которые испозуют pycharm или vscode.


                                                                                    А дальше очевидно куда, к кросс-платформенным нативным приложениям, типо flutter, qt и так далее. Что бы оно еще и быстренько работало.

                                                                                      0
                                                                                      Если в продукте она есть, но он приемлемо тупит, то можно попробовать.

                                                                                      Ну ок, если вы комфортно чувствуете себя в тормозящих приложениях, мне нечего вам возразить.
                                                                                      Но вот что будет через 5-10 лет ваять на qt (тоже весьма жирненьком) толпа нынешних js-синьоров прям хочется посмотреть.
                                                                                        0
                                                                                        Ну ок, если вы комфортно чувствуете себя в тормозящих приложениях, мне нечего вам возразить.

                                                                                        Мне нравится, как вы рассказываете про эти приложение не так, что они "ну, немного подтупливают в конкретных местах", а прямо тормозят.


                                                                                        На практике тот же vscode тупит исключительно в некритичных местах, а все важное, например, ввод текста работает в нем очень быстро.


                                                                                        Но вот что будет через 5-10 лет ваять на qt (тоже весьма жирненьком) толпа нынешних js-синьоров прям хочется посмотреть.

                                                                                        Всегда классно троллить программистов, которые сидят на других технологиях, пока не понимаешь, что по факту свою технология еще хуже.

                                                                                          0
                                                                                          На практике тот же vscode тупит исключительно в некритичных местах, а все важное, например, ввод текста работает в нем очень быстро.

                                                                                          Ну ок, я сужу по тому железу с которым приходится работать. Пробовал vscode — вернулся к sublime. Ибо на +- больших файлах было видно как построчно рендерится разметка. Может за год оно поменялось и ускорилось, но тут уже на вкус и цвет.

                                                                                          классно троллить программистов

                                                                                          дальше очевидно куда, к кросс-платформенным нативным приложениям, типо flutter, qt и так далее

                                                                                          Я троллю или вы? Типа по вашим словам гора написанного ныне электронового кода со временем будет переходить на флаттеры и кьюти. Вы в этой ситуации хотите чтоб js-разработчики отказывались от поддержки собственных приложений и участвовали только в стартапах или чего?
                                                                                          Типа да, выгодно какой-то прототип сваять на электроне и подцепить на него готовую вёрстку с работающего сайта. А поддержкой всего этого когда оно выйдет на промышленные масштабы будет заниматься кто?
                                                                                            0
                                                                                            Пробовал vscode — вернулся к sublime.

                                                                                            Да, sublime классный. Но я не смог на него вернутся из-за конфигов, которые слишком не типизированы.


                                                                                            Типа по вашим словам гора написанного ныне электронового кода со временем будет переходить на флаттеры и кьюти

                                                                                            Ну, вы спросили — что дальше. Раньше вот были приложения на java, теперь все обмазано электроном, я думаю, что в дальнейшем новые приложения уже будут писать на чем-то, что собирается в нативный код. Разумеется, старые приложение останутся на своем стеке, как и старые приложения на java.

                                                                              +2
                                                                              Типа rps'ы сами по себе не особо полезная метрика. Но обычно корреляция между rps и общей «отзывчивостью» приложения таки соблюдается.

                                                                              И возвращаясь к теме. Не знаю, как у вас, у меня опыт показывает, что обычно тупит неоптимальный код разработчиков, в духе "ой, вместо одного запроса к бд нахренашим 50", и каким бы классным не был язык, вас от такого ничего не спасет. А сами языки, ну, дадут вам 100 мс максимум.

                                                                                0
                                                                                А сами языки, ну, дадут вам 100 мс максимум.

                                                                                Вот тут как раз и применимы всякие бенчмарки, типа benchmarksgame-team.pages.debian.net/benchmarksgame/faster/node-gpp.html
                                                                                Вроде как код на всех языках там пытаются писать оптимальный, ан нет. На одних и тех же тестах разница между реализациями достигает десятков и сотен раз.

                                                                                Так же и с любым крупным проектом у вас будет выбор — либо докупить пару-тройку десятков серверов, либо переписать серверную часть на более эффективном языке.

                                                                                Где-то даже конференцию от того же яндекса находил. «Как вы оптимизировали обработку big-data на питоне? Нуууу мы переписали нагруженные места на c++ и выкинули питонячьи апишки для аналитиков»

                                                                                Да, я не отрицаю, интерпритируемые языки с высоким уровнем абстракций весьма полезны в своей нише, например когда сисадмину надо написать скрипт бэкапов или аналитику дёрнуть данные из базы. Но массовый переход разработки на это добро неизбежно приведёт к проблемам.
                                                                                  +1

                                                                                  О, класс, ссылки на бенчмарк гейм подъехали. В той репе, которую вы приводите в пример, например, аж один контрибьютор (хотя если ссылки на кучу других людей, которые вроде бы и писали этот код).


                                                                                  Да и даже без них, сравните ту же n-body задачу на С++ и python.


                                                                                  То есть в С++ люди опускаются до ассемблера и -03, который никто не использует в проде, а для питона использовать какой-то cython или numba уже нельзя, разумеется? Звучит как двойные стандарты на самом деле.


                                                                                  Когда вам нужен перформанс, вы опускаетесь на уровень ниже (Python -> C++/С -> Assembler -> hardware optimization), не совсем понятно, почему вы считаете это странным.

                                                                                    0
                                                                                    бенчмарки были к фразе
                                                                                    А сами языки, ну, дадут вам 100 мс максимум.

                                                                                    теперь вы говорите
                                                                                    Когда вам нужен перформанс, вы опускаетесь на уровень ниже (Python -> C++/С -> Assembler -> hardware optimization)

                                                                                    В итоге-то что? Зависит скорость программы от языка или нет?
                                                                                      0
                                                                                      В итоге-то что? Зависит скорость программы от языка или нет?

                                                                                      Опять же, в силу того, что статья про веб я говорил про веб-приложения и запросы. Напомните, когда веб-приложения выполняют синхронно бенчмарки? Мой тезис в том, что в веб-приложении не особо зависит.


                                                                                      С тем, что числодробилки стоит писать на низком уровне и прокидывать интерфейсы вроде никто особо не спорит.

                                                                                        0
                                                                                        Добавлю к вашему изречению ремарку, ибо не число дробилками едиными:
                                                                                        1) Если у вас сурово ограничен объем памяти.
                                                                                        Или
                                                                                        2) Если вам нужен суровый риалтайм
                                                                                        Или
                                                                                        3) Если вам недоступно горизонтальное масштабирование, а новая крутая железка стоит сильно дороже вашего времени
                                                                                        => Вы опускаетесь ниже на уровень абстракции.
                                                                                          0

                                                                                          Честно говоря, у меня очень крупные сомнения касательно того, что в случае с пунктов 1 или 3, особенно с 3, вы делаете все правильно. К первому пункту обычно можно прицепить какой-то IoT, но, честно говоря, их пишут на всем подряд и оно даже как-то работает.


                                                                                          Касательно пункта 2 в целом тоже, но там я хотя бы знаю условные области применения (типо алгоритмических торгов, онлайн игр и так далее).

                                                                                          +1
                                                                                          Статья вообще не понятно про что. Про то что если бэкэнд js переписать на сях и оптимизировать под одну конкретную задачу оно будет быстрее чем го?
                                                                                          Можно, в принципе, так для чего угодно сделать — пишем быстрый код на c++/c/asm -> выбрасываем в js апишку типа runMyProgram() -> радуемся какой js быстрый и оптимальный.
                                                                                          Мой тезис в том, что в веб-приложении не особо зависит.

                                                                                          Ну на сайте формата магазин — 10к товаров/2к посетителей в сутки мб и не зависит. На больших объёмах уже будет чувствоваться.
                                                                                          Веб-приложение — понятие растяжимое.
                                                                                            0
                                                                                            Ну на сайте формата магазин — 10к товаров/2к посетителей в сутки мб и не зависит. На больших объёмах уже будет чувствоваться.

                                                                                            Все так же не будет. Потому что вы, скорее всего, не будете делать поиск в приложении, а будете делать в базе данных и кешировать результаты. В противном случае на чем бы вы не писали, всегда будет мало.

                                                                                              0
                                                                                              А базы данных по вашему из воздуха рождаются? Их тоже так-то на чем-то пишут.
                                                                                              Приложение на js не будет тормозить, если узкие места не писать на js.

                                                                                              Блин, с этим тезисом я даже поспорить не могу.
                                                                                              Вообще, если по-сути, я считаю что основные преимущества js — дешевизна мультиплатформенной разработки и большое количество рабочей силы благодаря крайне низкому порогу входа, остальное — компромисы на которые бизнес идёт ради первых двух преимуществ. Что вы пытаетесь мне доказать я уже не понимаю.
                                                                              0

                                                                              Какая-то странная статья, вроде как по заголовку должно быть дофига сравнение, в конкретном направлении для node.js vs golang.
                                                                              А по факту немножко описывается биндинг имплементации WebSockets на крестах, который "значительно обходит по производительности лучшие решения, написанные на Golang"

                                                                                +1
                                                                                ждем связку golang + C/C++
                                                                                  0
                                                                                  cgo?
                                                                                    +1
                                                                                    я о том, что хочется увидеть сервер на go и C/C++ для каких-нибудь узких мест, ато очень мне нравятся сравнения, в которых голословные заголовки: «ЯП1 быстрее ЯП2». Но потом выясняется, что это не ЯП1 быстрее, а C/C++. В прочем, этот нюанс уже озвучили комментаторы сверху.
                                                                                    0
                                                                                    Что-то мне кажется, оно будет заметнее медленнее чистого Go из-за оверхеда cgo. Либо уносить в плюсовую часть практически всё, но это совсем уже странное решение. Go же берут не в последнюю очередь как раз из-за его рантайма и многопоточной разработки, а тут мы того лишаемся по сути.
                                                                                    +1
                                                                                    Не нашел в документации, что делать, когда тут не ОК

                                                                                    /* Ok is false if backpressure was built up, wait for drain */
                                                                                    let ok = ws.send(message, isBinary);

                                                                                    Так же непонятно, можно ли сделать цепочку из маршрутов
                                                                                    Например, когда верхний уровень ответственный за авторизацию, проверяет токен и вызывает либо next (для работы уже бизнес-логики), либо выдает ошибку авторизации. Тут похоже так не сделаешь и теперь надо во всех маршрутах в начале вставлять функцию проверки авторизации. (или опять же делать надстройку над этим сервером, и тогда все теряет смысл)
                                                                                    Опять же не увидел метода отправки ответа в json, это похоже тоже ушло с уровня фреймворка и теперь надо делать самому. Мелочь конечно, но вот из всего такого и складывается удобство использования.
                                                                                      0
                                                                                      В стандартных стримах ноды нужно дожидаться события drain nodejs.org/api/stream.html#stream_event_drain. Здесь, если я правильно понимаю, для той же цели есть unetworking.github.io/uWebSockets.js/generated/interfaces/websocketbehavior.html#drain
                                                                                        0
                                                                                        Спасибо, но все равно до конца не понятно…
                                                                                        Надо вызвать эту функцию, а потом переотправить текущее сообщение, или текущее сообщение уже отправлено и надо перед отправкой следующего вызвать эту функцию)

                                                                                        PS: В примере nodejs сообщение генерится в вызываемой функции, т.е. оно в любом случае новое будет, а что с текущим — не понятно, и надо ли приостановить отправку новых сообщений до отработки этой функции
                                                                                          +1
                                                                                          Как работает µWebSockets не скажу, не пробовал его. А в стандартных стримах повторная отправка не нужна. Если write() вернул false, отправку рекомендуют приостанавливать до события drain. Но даже если проигнорировать рекомендацию и продолжить слать данные — они в конце концов будут отправлены, ничего не потеряется. Правда, в этом случае nodejs начнет кушать память под буферизацию и памяти может в итоге не хватить…

                                                                                          Поэтому я люблю метод pipe() у стримов — если возникает backpressure во writable стриме, pipe() автоматически поставит на паузу readable стрим до события drain. Т.е. с pipe() в норме буферы не могут съесть памяти больше некоторой константы.
                                                                                          Правда, это полностью верно только для стандартных стримов. Если самому создать класс с интерфейсом Readable Stream и не позаботиться, чтобы у него pipe() работал корректно, то на жор памяти нарваться очень легко.
                                                                                            –1

                                                                                            Спасибо!

                                                                                      0
                                                                                      Делать было нечего дело было вечером. Решил протестировать простые сервера на node.js и golang через ab и JMeter — github.com/Garik-/http-benchmark

                                                                                      Библиотека µWebSockets.js ab не смог протестировать её, а JMeter показал результаты хуже чем обычный встроенный http на node.js.
                                                                                      Вы можете склонировать репозиторий и повторить тесты самостоятельно, пишите в issue пожелания и свои результаты.
                                                                                        +1
                                                                                        Не смог пройти мимо и прогнал тесты еще и на wrk + добавил реализацию на go fasthttp.

                                                                                        P.S. uWS тоже проверить не смог, но у меня она просто не собирается.
                                                                                          0
                                                                                          У меня все прекрасно собирается и бенчится и на рабочих Маках и на серверах Linux.
                                                                                          Даже поднял один продакшн на uWS. Вроде стоит, как скала.
                                                                                          По производительности пустых запросов у меня uWS в 3-4 раза быстрее нативного нодовского HTTP/WS и может легко соревноваться с не нодовскими серваками.
                                                                                          И при этом я все таки считаю, что для сетевого транспорта JS не нужен и лучше уж взять Actix на Rust и раз уж хочется логику писать на JS, то вызывать JS микросервисы из Rust.
                                                                                          Ну или если нет дружбы с ржавчиной, то взять Cишный uWebSockets

                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                      Самое читаемое