Web Framework Benchmarks раставил всех по своим местам

Разжуй — там таблица со сборной солянкой каких-то программ, написанных на разных языках и выполняющих разные задачи. Нихрена не понял.

ничоси, цпп быстрее всех для тупой отдачи plaintext!

Тесты популярных веб-фреймворков, либо библиотек на отдачу http response со всеми заголовками и контента в виде plain-text: «Hello World!» или json: '{«message»:«Hello World»}'.

Цифры показывают сколько таких респонсов может генерить фреймворк/библиотека за одну секунду на Dell R720xd dual-Xeon E5 v2 + 10 GbE.

Справа в таблице прописаны ЯП и ОС (могут быть сокращены, наводи мышку для полного названия). Слева название фреймворка/библиотеки, если raw, то значит ЯП предоставляет дефолтное API для создания веб-сервера и отдачи plain-text респонсов.

чем ближе задача приближается к реальной тем более одинаковыми становятся технологии

Жырнота уровня TIOBE.

Ну это лишь ваши домыслы. Ближе к реальным задачам можно глядеть на http://benchmarksgame.alioth.debian.org/ А вот тестирование веб задач приближенных к реальности пока не видел.

Ну так что? Си++ и Ява. Остальные в пролёте. Причём среди либ на Яве есть огромное количество аутсайдеров, а Си++ держится вверху таблицы.
В общем все стереотипы остались на местах: Си++ быстр и вообще молодец, а Ява тормозная (и только редкие коллективы гениальнейших программистов могут на Яве писать что-то аналогичное по производительности с Си++)

Какой бред то там написан

По своей практике - Wicket в сотню раз меленней Spring

Быть может весь прикол в том, что данный тест придумывал похапэшник, и он не знает, что веб-фреймворк не отдает plain text, а генерирует данные и формирует страницы сложным образом

В частности, Wicket на такую генерацию может тратить десятки мегабайт RAM на 1 запрос плюс просадка по скорости, а Spring на том же запросе не потратит почти ничего, поэтому разница между ними видна просто невооруженным глазом. На викете щелкнул ссылку - и можешь пойти попить чай.

Скорей всего там вообще всё так же сделано в этом тесте через жопу

Наверное, они там живут в светлом эльфийском мире, где весь UI рисуется на клиенте, данные подсасываются через JSON, и от веб-фреймворка вообще ничего не требуется кроме того как отдать несколько символов плейнтекстом (рыбу html-документа, поверх которой будет рисовать angular)

Непонятно только, зачем в такой схеме вообще потребовался веб-фреймворк, почему не просто nginx

Ну это лишь ваши домыслы

как скажешь)

Ближе к реальным задачам можно глядеть на http://benchmarksgame.alioth.debian.org/

лал, нет
ближе к реальным задачам можно глядеть на работе

что данный тест придумывал похапэшник

Не, PHP в самом конце таблицы оказался. Не совпадает.

web2py смог отдавать по два ответа в секунду?

По своей практике - Wicket в сотню раз меленней Spring

Сырцы доступны можешь глянуть реализацию:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Jav...

https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Jav...

Судя по всему Spring задействует весь MVC оверхед, а Wicket отдает все напрямую.

и он не знает, что веб-фреймворк не отдает plain text

Это да, данный бенчмарк лишь показывает специфичную область. Например, надо тебе отдавать котировки в реальном времени, посмотришь на этот тест и поймешь какой ЯП+либу нужно юзать.

Организаторы данного бенчмарка не виноваты, что им отправляют реализации на разнообразных фреймворках, которые не умеют напрямую отдавать plain-text, а подключают для этого кучу оверхеда.

Что за Ulib такой? Судя по репозиторию вообще поделка одного программиста выложенная в паблик.

Как так получилось, что оно всех практически во всех тестах обгоняет?

и только редкие коллективы гениальнейших программистов могут на Яве писать что-то аналогичное по производительности с Си++

Нет, для этого не надо быть гением, для этого достаточно не быть индусом. В java топе - либы, которые написаны белыми людьми, а не на аутсорсе у индусов.

все на плюсы посоны

Самое главное забыл — что это навсегда!

netty 57.5%

Это что веб рамка разве?

Скорей всего там вообще всё так же сделано в этом тесте через жопу

это точно. ТС вбросил и сбежал

ЯННП.

Вижу только, что ulib и rapidoid лучше всех.

может это поделка автора теста?

Этой поделке уже пара лет.

Ну с разморозкой вас. Вы не на цифры глядите, а на код тестов.

Все открыто и документировано можешь как оценить сырцы, так и запустить у себя и проверить https://github.com/TechEmpower/FrameworkBenchmarks

Причем тут разморозка? На этот раз в бенчмарки добавили rust и vibe.d наконец-то запустился, стали доступны цифры по нему. К тому же Go обновился на новый GC и Mono там чето заявляет, что они готовы к продакшену.

А что мне в сырцы смотреть? Что я там не видел?

С одной стороны, некая практическая информация там есть — можно увидеть аутсайдеров (в основном там что что никто не использует) с феерическим оверхедом.

Но я согласен с предыдущими ораторами — тесты на hello world нерепрезентативны. Ты же не сравниваешь СУБД по селекту из таблицы с одной строкой. А то ведь окажется что sqlite уделывает вообще всех. Значит переходим на sqlite?

Впрочем, выводы сделать можно — для большинства фреймворков отдача простых запросов не проблема. Но это и так было известно.

http://benchmarksgame.alioth.debian.org/ А вот тестирование веб задач

Вот-вот, на benchmarksgame не сравнивают ЯП по скорости вывода hello world на экран. Ещё раз, вывод строки из 11 символов это не «веб задача».

Эти бенчмарки вполне показывают оверхед фреймворка и оптимизации в ЯП при мультитрединге для задач уровня REST сервисов. По ним можно сравнивать оверхед jetty vs undertow vs netty. Или смотреть на что сегодня способен D или Rust.

Для себя лично, я вычеркнул dropwizard из списка фреймворков для REST сервисов. Отставать от Tapestry или Wicket в 2-3 раза, которые не предназначены для разработки REST. Или ~15 раз от Undertow, определенно ему не в плюс.

К тому же открыл для себя Rapidoid, на котором конечно все сделано очень низкоуровнево в данных тестах. Но я как раз искал подобную платформу для разработки фреймворка. И раньше ориентировался на Undertow, но теперь буду изучать его.

Да всё это херня. Vibe.d - обёртка над libevent и на одном ядре plain text он отдавал в моём тесте со скоростью 5509 req/sec, тогда как java undertow около 4500. Никогда java не обгонит libuv / libev / libevent.

И раньше ориентировался на Undertow, но теперь буду изучать его.

Изучай vert.x на java. Там всё грамотно и скорость на уровне любимого undertow. Ты просто сам потести их - это не сложно. А изучать D ради vibe.d не совсем целесообразно - выиграешь 10% всего-лишь в скорости, при этом придётся отказаться от IDEA, от нормальных utf-16 строк и т.п.

Лично я бы выбирал то на чём удобнее писать. Я не знаю что ты программируешь, может у тебя своя серверная ферма миллионы qps супер-мега проект.

Но в моём мире если сервер может отдавать хотя бы 100 qps на ядро на реальных запросах то это уже очень хорошо. Даже с таким qps на 16-ядерной тачке можно отдавать десятки миллионов qps в сутки. Поэтому глубоко пофигу сколько hello world ответов может отдавать фреймворк потому что обычно упирается не в это (кроме совсем клинических случаев, конечно).

И обычно нет проблемы обслужить клиентов если архитектура нормальная. Обычно проблема а) раскрутиться и привлечь аудиторию б) реализовать задумки в коде. И тут очень хорошо если не приходится сражаться с фреймворком. Сейчас дешевле купить/арендовать мощную железку чем выжимать все соки из слабого сервера и насиловать девелоперов переоптимизированным кодом и круглые сутки гонять нагрузочные тесты. Лучше эти силы направить на расширения функциональности.

Моё имхо. tailgunner, что скажешь?

может у тебя своя серверная ферма миллионы qps супер-мега проект

Судя по серьезности отношения к этой недосинтетике, он старший админ низколатентного локалхоста.

А ещё можно язык программирования выбирать по тому, насколько быстро он выполняет пустой цикл.

Лично я бы выбирал то на чём удобнее писать

Почему бы не сделать и удобно и быстро? Я поставил перед собой именно такую цель. К тому же сейчас нет фреймворков на которых удобно писать современные веб-проекты.

Почему бы не сделать и удобно и быстро? Я поставил перед собой именно такую цель.

Как я всегда говорю в таких случаях: дерзай :). Даже если ничего не получится ты получишь опыт.

Но чем ближе твои эксперименты к практике тем более ценный опыт ты приобретёшь. Бездумно гоняться за большими циферками не стоит. И, конечно, скорость меряется не через hello world. Ну просто потому что если будет стоять такая задача то я тупо напишу вебсервер на си возьму готовый код с гитхаба заточенный под эту задачу.

К тому же сейчас нет фреймворков в мире Java на которых удобно писать современные веб-проекты.

fixed for ya

раставил всех по своим местам

О да, феерическая расстановка точек над.

Заглянул ради интереса в тестируемый код на vibe.d - тупо реализация с ошибками, на протухшей версии (0.7.19 - вышла больше года назад), собранную протухшим компилятором, от какого-то левого чела. Интересно, с другими фреймами такая же порнота?

Автор vibe выкатил pull в гитхаб TechEmpower с исправленем боков. Ждем следующего сезона, пока - ни о чем.

Ждем следующего сезона, пока - ни о чем.

Какие привередливые, все вам не так и не эдак )

А ещё можно язык программирования выбирать по тому, насколько быстро он выполняет пустой цикл.

Ну там есть тесты и посложнее https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test... - вот этот более приближен к боевым условиям, там и шаблоны генерятся и контент рандомный. Но фреймворков конечно меньше.

Никогда java не обгонит libuv / libev / libevent

И на java можно обертку запилить, вот например ребята из одноклассников запили собственный IO и HTTP сервер на java обернув нативные либы: https://github.com/odnoklassniki/one-nio

Own native socket library.
APIs for managing gigabytes of RAM beyond Java Heap.
Fast and compact serialization mechanism.
RPC client/server technology which is an order of magnitude faster than Java RMI.

Но когда я последний раз смотрел, оно вроде HTTP2 не умело, как сейчас хз.

APIs for managing gigabytes of RAM beyond Java Heap.

https://github.com/odnoklassniki/one-nio/search?utf8=✓&q=unsafe

Причем тут разморозка? На этот раз в бенчмарки добавили rust и vibe.d наконец-то запустился, стали доступны цифры по нему. К тому же Go обновился на новый GC и Mono там чето заявляет, что они готовы к продакшену.

По заголовку подумал что вы только увидели этот бенчмарк.

А что мне в сырцы смотреть? Что я там не видел?

Смотреть код. Код выдает одинаковый результат, но результат получается различным способом. В итоге да мы можем увидеть что компилируемые языки быстрее интерпретируемых, можем видеть где сделана оптимизация io. Но полной картины мы не увидим, это все еще синтетические тесты. Хотя если у вас задача отдавать тупо hello world то наверное да, эти тесты вам подходят. Советую попробовать взять один из тестов и оптимизировать, я уверен при должном знание яп вы улучшите показатель минимум раза в 1.5-2 раза.

Забавно что когда на один запрос приходится обращаться много раз в БД, всех уделал Дарт, лол. https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test...

Ну это лишь говорит, о том, что у него меньше оверхедов в драйвере к монге. Да и это больше тест БД, чем ЯП. Достаточно глянуть undertow edge на Pg и Mo, чтобы понять, что скорее всего дрова на монгу в джаве кривые.

Если бы это было так, то в тесте один бд запрос на реквест дарт тоже лидировал бы, а там ц++ почему то, что-то здесь другое.

поэтому разница между ними видна просто невооруженным глазом

Где?

что где? На секундомере, епта. Спринговая страница рендерится мгновенно, а на викете можно успеть налить чаю, или даже выпить его (в зависимости от сложности страницы). В top сервера по загрузке проца и RES RAM.

а все потому что создатели Wicket'а криворукие дебилы, за которыми потом нужно переписывать весь фреймворк, чтобы он начал работать. Игоря Вайнберга можно простить хотя бы за существование select2, остальных - отправить проходить школьный курс информатики, сложность алгоритмов, итп. После прохождения, когда они осознают свои ошибки - расстрелять.

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

Первое. foror, солнышко, как так получилось, что ссылки наброшены на те тесты, которые к реальной жизни имеют меньше всего отношения? Вот так же надо: https://www.techempower.com/benchmarks/#section=data-r11&hw=ec2&test=...

Второе.

https://github.com/TechEmpower/FrameworkBenchmarks/issues/1718

Ъ: Используется древний и протекающий Go 1.1 и 1.2, когда актуальная версия с новым GC - 1.5.1. К следующему раунду, когда выйдет Go 1.6 они обещают обновиться до 1.5. И так во всём. Например, revel фреймворк тянут из github.com/robfig/revel, хотя он уже 2 года, как переехал оттуда.

Третье. Возможности по оптимизации безграничны. Например, для JSON можно использовать стандартную библиотеку с reflect, а можно увеличить производительность в несколько раз, используя ffjson.

Для генерации случайных чисел можно использовать стандартную библиотеку, а можно (коль это узкое горлышко теста) взять многопоточную реализацию: https://github.com/TechEmpower/FrameworkBenchmarks/issues/1469.

Можно использовать стандартный http сервер, а можно повысить производительность в 10 раз, заменив его fasthttp.

Поэтому, если есть авторы, заинтересованные в высоких циферках, они оптимизируют нужный фреймворк. Если таких нет, специалист по всем языкам, он же сотрудник TechEmpower сам делает как считает нужным.

* как считает нужным - как проще (читай: как написано в документации стандартной библиотеки).

А почему не https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test... и графы с отметкой «ORM: Ful»?

Быть может весь прикол в том, что данный тест придумывал похапэшник, и он не знает, что веб-фреймворк не отдает plain text

Вообще-то, там разные варианты есть. Это проблема топикстартера, что он выбрал последнюю закладку с plain text, которая, скорее, просто для иллюстрации идёт.