Comments 26
Оригинал 2013 года, в мире nodejs это геологическая эпоха.
Думаю, если бы взяли Clojure, количество строк и файлов и времени потрачено было бы еще меньше…
И точно так же можно было писать и фронт и бек на одном языке используя «мощь фулстека».
А сам по себе язык гораздо более технологичен, что безусловно скажется в итоге.
К тому же замеры производительности вызывают вопросы. На сколько корретно было это сравнение?
Оптимально ли было написано JVM приложение?
Что-то я очень сомневаюсь, что JVM настолько проигрывает NodeJS в производительности.
NodeJS vs Java напоминает https://habrahabr.ru/post/153225/ :)
Спустя два месяца разработки на Java, два разработчика стали параллельно работать над Node.js приложением.
Построено в дважды быстрее с меньшим количеством людейНемного не правильное утверждение, т.к. когда задача уже сделана и нужно сделать «точно так же», это всегда будет в 2+ раза быстрее, чем узнать все требования и написать с нуля.
Да и Java для рендеринга html никогда не была хорошим решением. На ней можно это сделать, но это больше в угоду единому стеку разработки, нежели производительности.
Для фронтенд-сервера, действительно, лучше использовать что-то типа Node.js, А для API сервера, особенно с тяжелой логикой и/или расчетами, лучше брать компилируемый и типизированный язык (Java, C#, Go).
ps: но все же к результатам теста в статье есть недоверие. Скорее всего тест был проведен на холодном старте, без прогрева JVM / Node.js, думаю, на прогретой JVM, разница была бы не столь велика.
одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.
никто не знает, кто что и как комитил в этот собственный фреймворк.
Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
При переписывании всегда будет меньше и быстрее, не важно какая новая платформа.
Я понимаю что это перевод и все таки спрошу. Вы сами понимаете смысл цифр в таблице? Я вот например если правильно понял у paypal было около 8 rps а стало около 15rps. Было время ответа около 1с а стало 600-800 мс. Но я все таки надеюсь что я что-то не так понимаю
Если запутались именно в таблице, то в шапке таблицы (прям под синими столбиками) написано к-во страниц которое загрузилось за секунду, а ниже данные для каждой конкретной страницы.
Я просто к тому что цифры какие-то не серьезные и для Java и для Node.js. К примеру даже на банальном PHP цифры получаются совсем другого порядка. Первая же ссылка в гугле — https://github.com/kenjis/php-framework-benchmark Цифры начинаются от 100 и заканчиваются на 2000 rps. Правильно организованная Java должна брать 2-3k rps
Как я понял понял, по вашей ссылке тест реализаций Hello world в разных фреймворках. Странно это сравнивать с /wallet в PayPal.
В статье нету никакой информации про то что приложение выполняет под капотом и какая там реализация. Допустим, если приложение делает 2 запроса на другие сервера (авторизация и получение данных), то при классическом подходе на Spring troughput будет ниже, чем на Node.js, банально из-за того, что все время проведет в ожидании io (но на Spring можно написать такой же асинхронный код, как и на node.js).
Я согласен что нельзя ожидать что в реальных проектах скорость будет такая же как в синтетике. Просто Вы правда считаете что для реального проекта 15 rps/ 1s на ответ это норма?
Но это платежная система. Она должна обеспечивать высокий уровень безопасности пользователя, а для этого нужно собрать много метрик и сделать много проверок (девайс, браузер, куки, геолокация, время суток и еще черт знает что). И скорее всего, тот сервер, который они тестировали — лишь проксирует эти данные на другой сервер.
Это объединяет наших специалистов в одну команду которая позволяет нам понимать и реагировать на потребности пользователей на любом из уровней наших технологий.
… мы скоро будем открывать его исходный код!...
И далее по тексту еще есть подобное.
шикарный исследовательский подход… особенно радуют выборки — 1 пользователь, 5, 10… серьезно? )))
а если по существу, делать корректные, воспроизводимые бенчмарки — это не просто замерить время вызова одной странички…
Плотники зато знают, какая пила пилит быстрее:)
если paypal выяснили, что node.js для них оптимальный выбор — это хорошо, вопросов нет…
мой комментарий был акцентирован на то, что представленные графики времени отклика неверно составлены… более показательны были бы графики зависимости latency от bandwidth на всем диапазоне кол-ва запросов — от нулевого до максимального… и при этом стенды испытаний, чтобы были одинаковы…
Nope. Есть пила для пиления поперек волокон, есть пила для пиления вдоль и есть универсальные (пилят и так и эдак, но похуже). Но споров не будет — плотники-то знают, какая пила для чего.
Правда, у плотников было несколько тысяч лет, чтобы выяснить, какие пилы для чего предназначены, а у программистов и ста лет еще не было.
Node.js в PayPal