Comments 36
Вывод в node.js вы конечно же в sync режиме использовали???
Node.JS это не язык, а платформа с использованием движка V8 для js.
А так же поправить табличку потребления памяти у Laravel с учетом вебсервера (потому что nodejs — это полноценный сервер приложений, включая http-сервер).
Всё тестировалось без кэширования. При включенном кэшировании данные, конечно же, несколько другие, но картины не меняют.
Вот это вы напрасно! Обычно, проводя нагрузочные тесты фреймворков для последующего сравнения результатов, подразумевают тестирование не способа генерации вывода данных (тут принципы почти одинаковы), а тестирование именно возможностей кэширования, что и куда кэшируется (тут отличительные принципы есть у каждого фреймворка).
Столбик Memory consumption во второй таблице немного непонятен.
В случае с Laravel и Yii, как я понимаю, показывает heap процесса после отработанной генерации одной странички.
А в случае с Rails и SailsJS Вы показываете heap всего сервера.
Что из этого следует? Если, например, запустить одновременно 10 потоков генерации странички Laravel, то объем общей занятой памяти на тестируемый момент будет 19.32 × 10 = 193.2Mb. В этих же условиях, не факт что Rails и SailsJS принципиально увеличат объем занятой памяти.
Кэширование тоже бывает разным. Но интереса ради включу везде кэширование и проведу отдельный тест.
По поводу замера размера памяти — я, конечно же, понимаю, что так сравнивать не совсем корректно, но руби и нода стартуют сервером, в то время как встроенный сервер php — совсем не производительное решение.
Как вариант, конечно, перевести всё на один веб-сервер + подключить обработчики для языков. Хотя нода в любом случае будет запускать свой сервер, к которому нужно будет делать upstream.
По поводу замера размера памяти — я, конечно же, понимаю, что так сравнивать не совсем корректно, но руби и нода стартуют сервером, в то время как встроенный сервер php — совсем не производительное решение.
Как вариант, конечно, перевести всё на один веб-сервер + подключить обработчики для языков. Хотя нода в любом случае будет запускать свой сервер, к которому нужно будет делать upstream.
Кэширование тоже бывает разным.
Платформы тоже могут быть по-разному настроены. В NodeJS есть возможность загрузить какие-то данные в память один раз и пользоваться этими данными при выдаче каждой страницы. В php такое возможно лишь с использованием memcached и их аналогов. Существует также LRU-cache — это как кэш кэша. Значения наиболее популярных блоков памяти хранятся в одном массиве для наиболее быстрого доступа к ним.
Также, результаты могут отличаться как в лучшую, так и в худшую стороны, если php будет запускаться с какими-нибудь ioncube, zend optimizer, eAccelerator.
Для сравнительных тестов NodeJS, Ruby и PHP было бы справедливо суммировать затраченную память и CPU-time всех PHP-процессов и всех процессов вебсервера — Apache или Nginx или что-то еще (вы не указали).
Советую проводить нагрузочные тесты вот этой утилитой:
httpd.apache.org/docs/2.0/programs/ab.html
в то время как встроенный сервер php — совсем не производительное решениеВы так пишете как-будто Webrick (встроенный сервер для Ruby) — производительное решение. Добавьте в Gemfile строку
gem 'thin'
и посмотрите ещё раз (после bundle install).
А по теме статьи, Вы по сути выбираете из медленных технологий. Рассмотрите Elixir+Phoenix и Golang+Gin, если производительность без кеша имеет значение для вас :-)
Идиотский вопрос, но вас не смутило, что в PHP константа M_PI, это аналог функции pi() — и она вычисляет PI с заданой в php.ini точностью, ВЫЧИСЛЯЕТ. А в JS Math.PI — как я понял тупо предопределенная константа, те число зашитое в исходник? Если я не прав, расскажите, как изменить точность Math.PI или ткните меня в исходники бибилотеки Math для JS.
В третьем тесте у питона 0.44s, а у ноды 0.68s. Я что-то не понимаю в выделении жирным?
Забавно, но если просто обернуть PHP код из репозитория, для генерации Pi в класс и метод, то даже PHP 5.6 справляется за 4.8 секунд, смею предположить, что результат PHP 7 будет быстрее. Не знаю с чем это связано, но есть какой то подвох. Может связанный с объявлением глобальных переменных.
В то же время если обернуть JS, ни чего по таймингу не изменится.
В то же время если обернуть JS, ни чего по таймингу не изменится.
Да, еще одно замечание автору. Не совсем по теме статьи, но я посчитал полезным и оставлю здесь.
В исполняемом скрипте SailsJS
Данность явно указывает на то, что javascript вы знаете по front-end-у.
Такая конструкция уместна для изоляции переменных и прочего кода в браузерах, так как все скрипты работают с одной областью видимости
В Node.JS каждый модуль запускается в собственной области видимости
Гораздо большего эффекта можно добиться, например, от strict-режима, чего в ваших скриптах не наблюдается:
В исполняемом скрипте SailsJS
app.js Вы обернули код в конструкцию:(function(){
})()
Данность явно указывает на то, что javascript вы знаете по front-end-у.
Такая конструкция уместна для изоляции переменных и прочего кода в браузерах, так как все скрипты работают с одной областью видимости
window.В Node.JS каждый модуль запускается в собственной области видимости
module. Такая обертка у чисто серверного скрипта выглядит весьма странно.Гораздо большего эффекта можно добиться, например, от strict-режима, чего в ваших скриптах не наблюдается:
'use strict';
В случае с SailsJS использовал генератор проекта от самого Sails. Он и создал такой файл, его я не менял.
И вообще, если в фреймворке есть средства генерации кода — я его использовал. Это касается всех приведенных в статье фреймворков.
И вообще, если в фреймворке есть средства генерации кода — я его использовал. Это касается всех приведенных в статье фреймворков.
А лучше вы бы этот использовали — github.com/ghaiklor/generator-sails-rest-api
Тот генератор, который идет в поставке с Sails, убогий и ничего толкового не умеет.
Тот генератор, который идет в поставке с Sails, убогий и ничего толкового не умеет.
комментарий удалён
Инструменты надо выбирать по задачам. Если у вас админка — в принципе наплевать, сколько будет генерироваться ответ с сервера, зато важна скорость разработки.
Если у вас реалтайм и вебсокеты, php в принципе рассматривать не стоит, не для этого он сделан.
А если уж тестируйте — делайте это правильно. У вас, судя по коду, куча копипасты с SO, или аналогов. Напишите везде один и тот же алгоритм.
Как вы тестировали затрачиваемую память — вообще не ясно.
Если у вас реалтайм и вебсокеты, php в принципе рассматривать не стоит, не для этого он сделан.
А если уж тестируйте — делайте это правильно. У вас, судя по коду, куча копипасты с SO, или аналогов. Напишите везде один и тот же алгоритм.
Как вы тестировали затрачиваемую память — вообще не ясно.
Очевидно, есть какая-то странность, что NodeJS так всех обогнал.
Не могу только понять какая…
Не могу только понять какая…
Ересь какая-то. Сравнение теплого с мягким. В синтетических тестах. Баз каких-либо оптимизаций под указанную задачу в данном языке.
Интересно, и часто в проектах на PHP и RoR приходится экспоненту вычислять?
Первый тест — вычислительная задача, чтобы количественно сравнить php/ruby/js+node.
Практического смысла, понятное дело, не имеет. Это показатель того, как языки (и нода) справляются с вычислениями.
Второй тест — более приближенный к жизни, хоть и показывающий простой и банальный use-case приложения.
Практического смысла, понятное дело, не имеет. Это показатель того, как языки (и нода) справляются с вычислениями.
Второй тест — более приближенный к жизни, хоть и показывающий простой и банальный use-case приложения.
Да в общем никогда. Как и использовать PHP и RoR, если нужна производительность.
Фэйсбуку и Гитхабу производительность не нужна? :)
У Фейсбука столько легаси кода, что переписать его не получилось. Оказалось проще написать сначала транслятор в си, а потом свою виртуальную машину для php. Которая по производительности всё равно проиграет банальной джаве, не говоря уже о каком-нибудь Go. Если бы отыграть время назад, никто бы и не подумал делать Фейсбук на php. На одном только электричестве сэкономить миллионы можно.
У гитхаба запросы по производительности в сотни раз меньше, ему хватает того, что есть
У гитхаба запросы по производительности в сотни раз меньше, ему хватает того, что есть
Если бы отыграть время назад, никто бы и не подумал делать Фейсбук на php.
С одной стороны, история не знает сослагательного наклонения, а, с другой, не думаю, что Цукерберг бросился бы изучать Java, обладая сегодняшними знаниями о том как взлетела поделка на PHP. Там может задержка релизов на день была критична.
Мне показалось, что поставленная задача (цель) не коррелирует с проведенными исследованиями
Зачем, если уже есть www.techempower.com/benchmarks
Там хоть данные, близкие к практическим, т.е. работа с сетью, а не числодробилки и рекурсии, которые на практике оптимизируют по-всякому.
Там хоть данные, близкие к практическим, т.е. работа с сетью, а не числодробилки и рекурсии, которые на практике оптимизируют по-всякому.
Хотелось бы хотя бы в общих чертах понять, какие насущные проблемы в web-программировании решает скорость вычисления числа PI.
Sign up to leave a comment.
Сравнение языков программирования и фреймворков для них