Какой выбрать язык для серверной части highload проекта?

Question

[Andy Vo]

Доброго времени суток.
Есть большой проект и мне выпала честь переписать его логику.
Цель такова:
Сделать все вычисления, записи и прочее касаемо логики проекта отдельно от всего. Что бы веб и мобильные версии просто отправляли запросы на логическую часть и она выполняла все основные операции.
Сразу скажу основные претенденты Python и NodeJs.
Я смотрел различные статистики и где-то python, где-то nodejs лучше.
От проекта требуется хорошая производительность с малым потреблением ресурсов (сервер мощный, не подумайте). Определённо будет большой кол-во обращений к PostgreSql базе.
Не знаю какой язык и фреймворк выбрать под такие нужды.
Товарищ подталкивает написать всё на C++ и идея впринципе не плохая, но переживаю за скорость разработки и стабильность проекта.

Comments

[Andy Vo]

Точный трафик не припомню. Но за день больше 10к на сайт.
Веб версия сама сейчас написана на PHP+Symfony и скорость работы этой связки не устраивает. Нужно что то более шустрое.
А на тему Python - лучше на чистом или какой-нить фреймворк посоветуете?

[KorsaR-ZN]

Ну 10-100к за сутки, это не большая нагрузка.
Берите PHP + Phalcon, и делайте RESTful API для фронт частей (веб, мобильный апп)
Если все таки хотите Python, чистый не к чему, возьмите Django REST Framework

[Юрий Ярош]

Да, в принципе можно взять тот же Phalcon, нормально кэшировать запросы в БД и не заморачиваться. Если у вас модель БД "черезодноместо", а так оно бывает у 80% людей которые задают подобные вопросы, то тут никакой фреймворк/язык/законы вселенской магии не помогут вам сделать ваш сервис быстрее - нужно было нормально организовывать работу и проводить QA.

[un1t]

Блин, я думал хайлоэд. 10к в день хоть на Джумле пиши, тока кеш настрой. С++ тут точно не нужен. Любой язык справится. Асинхронность тут точно не нужна.

Answer 1

[Юрий Ярош]

Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

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

Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.

Comments

[Viktor Vsk]

Поправьте, если ошибаюсь, но на 14-17к умирают не только интерпретируемые языки, но и такие вещи как веб-серверы, например.
Не имею особого боевого опыта в таких порядках, но разве есть смысл разрулить такие масштабы за счет "скорости" языка и сборки мусора вместо горизонтального масштабирования?

[Юрий Ярош]

Виктор Ablebeam: на 17К запросов вэбсерверы типа nginx помирают только если их неправильно готовить, да и на 17К запросах они бывают вовсе ненужны. Ну не зря же сейчас достаточно много проектов на рельсах слезли на golang и уменьшили количество своих серверов в 4-5 раз, а в случае с typesafe stack и Amazon'ом получилось в 8, хотя там это напрочь убило RAD.

[Viktor Vsk]

Юрий Ярош: Не видел nginx с более чем 12-20к на воркер.
А про горизонтальное масштабирование неправильно немнорго выразился. Имел ввиду не только сервера докупать, но и распараллеливать.

Разве будут особые проблемы от руби, если потоко-безопасный код на рельсах форкнуть пару раз ?

[Юрий Ярош]

Виктор Ablebeam: если в двух словах - проблемы будут.
Я понял - речь была о вертикальном масштабировании со стороны Ruby.
Нет простым vfork'ом и тонной воркеров тут проблему не решить.

1 запрос <=> 1 воркер/поток в одном процессе - путь в ад. Просто адовые накладные расходы на создание воркеров/потоков и довольно большой overhead по блокировке и переключению контекстов - обычно люди забывают что и в ОС тоже есть свой шедуллер, и он влияет :).

Много запросов <=> (количество ядер * 2) воркеров/потоков в рамках одного процесса- обычно оно так и делается, желательно в рамках какой-то producer-consumer модели типа disruptor или модели актёров аля akka, erlang, golang, greanlet'ы и т.п. Самопальные disruptor'ы проще контролировать и оптимизировать расходы памяти.

Есть ещё такие вещи как pfRing и netmap, и offheap кэширование - ну вот банальный redis vs terracota это 50 к 1 по скорости обработки fetch'a с хэш-таблицы. Когда микросервисные архитектуры делают через "одноместо", то подобные оптимизации абсолютно бесполезны и часто просто напрочь убивается вертикальное масштабирование... но тут уже речь идёт о трафике формата одноклассников или stackoverflow.

[Viktor Vsk]

Юрий Ярош: интересно, спасибо )

[sim3x]

А почему все слезли голанг, а не на java/jvm?

[Юрий Ярош]

sim3x: потому что в JVM время компиляции на много больше и соответственно период повторного прогона тестов выше, в том же Goconvey можно гонять тесты каждые 1-3 секунды. В gradle с демоном на тот же самый объём тестов и исходников уходит в среднем 7-15 секунд, не учитывая времени выполнения самых тестов которое обычно происходит довольно медленно.

[sim3x]

Юрий Ярош:
А чье мнение советуешь почитать про внедерние голанга в корпорациях?

[Юрий Ярош]

sim3x:
https://habrahabr.ru/company/yandex/blog/237985
https://digitaloctober.ru/ru/events/golang_moscow
https://events.yandex.ru/lib/talks/2222/
https://events.yandex.ru/lib/talks/1457/
https://events.yandex.ru/lib/talks/2308/
https://events.yandex.ru/lib/talks/1454/

[sim3x]

Юрий Ярош: спасибо огромное!
А кого-то на английском?

[Юрий Ярош]

sim3x: Один из устаревших примеров экономии на оборудовании
blog.iron.io/2013/03/how-we-went-from-30-servers-t...

[Юрий Ярош]

sim3x: вот достаточно поучительный антипост о ноде
techblog.netflix.com/2014/11/nodejs-in-flames.html

[sim3x]

Юрий Ярош: про антиноду TJ все рассказал :)

[sim3x]

Юрий Ярош: а вот наводка на блог нетфликса - бесценна!

[Юрий Ярош]

sim3x: кстати да... а я уже совсем забыл что он на golang тоже уполз.
В любом случае я сяду летом штопать порт golang'а под JVM, возможно даже сагитирую Дмитрия Вьюкова... так что будет ещё веселье в нашем детсаду.

[Юрий Ярош]

sim3x: skype void.nugget если чего надо ...

Answer 2

[xmoonlight]

php - все будет в лучшем виде, если руки "прямые".

Comments

[Komly]

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

[Юрий Ярош]

Komly: ждём phpng, надеемся на jit и ассинхронносити с многопоточностями ∞)

Answer 3

[KorsaR-ZN]

Если стоит выбор между Python и NodeJS, берите однозначно Python, в NodeJS намучаетесь с его асинхронностью.
С++ конечно хорошо, но на мой взгляд будет сильно тормозить скорость разработки, да и можно нарваться на подтекании памяти.
Так, что берите Python, хотя можете присмотреться к PHP и фреймворку Phalcon

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

Comments

[Тимофей]

В node.js есть async для организации асинхронного кода. И вообще с асинхронностью не надо мучатся, надо просто к ней привыкнуть. Сам юзаю ноду после пыхи и руби. Поначалу, действительно, мозг взрывался, но теперь асинхронный код для меня стал вполне нормальным.

Не холивара ради, просто личные наблюдения)

[un1t]

Про async в курсе и про промисы тоже,. Это отчасти улучшает читаеместь кода, но все-таки геморой остается значительным. Плюс есть еще другие притензии к ноде. Скорость работы разных библиотек, их наличиие и их качество. С этим у ноды пока все достаточно печально. В питоне есть асинхронные фреймворки, например Tornado, в нем код выклядит намного прямее засчет yield. А в третьем питоне еще прямее за счет yield from. Т.е. визаульно код очень становиться похож на синхронный. Если у вас не чат, какой-нибудь, то не факт что нужна эта асинхронность, даже не больших нагрузках. Дело в том, что на больших нагрузках, все что можно отдается из кеша, и тут уже без разницы синхронный код или асинхронный, кеш отдать досаточно быстро можно при любом подходе.

[Александр Прозоров]

un1t: флаг --harmony и здравствуй yeld в node.js

[un1t]

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

Answer 4

[index0h]

С нодой очень вероятно - хлебнете горя на утечках памяти. Нода - конечно не плохая штука, но вы должны понимать, что ограничены N потоков запросов к БД, где N - количество CPU(в случае, если модуль кластер использовать не будете N = 1). То, что касается IO - нода очень даже синхронная.
На счет C++ - будьте осторожны, скорость разработки и поддержка вероятно будут больным вопросом.
На счет питона ничего не скажу.
Можете посмотреть в сторону Golang или Java.

Вообще говоря - нельзя подбирать технологию по паре абстракций типа "работа с postgre", "логика проекта", "highload")) Это как подбирать пароль зная, что но был написан на желтой бумажке. Слишком мало информации.

На счет HL: возможно скажу спорную штуку, но если вы ориентируетесь на HL - даже не предполагайте того, что сервер будет один.

Comments

[KorsaR-ZN]

Дайте пожалуйста пруфф про i\o синхронность в ноде. Буду очень благодарен.

[Юрий Ярош]

._.
Нода как-бэ асинхронная, но потом она всётаки синхронная... и это влияет на производительность.
Берём профилятор и смотрим что где и как блокируется, а то блин звучит реально тупо...
Ещё тупее утверждать что каждый поток блокируется на время запроса к БД - это уже зависит от криворукости разработчиков самого драйвера и разработчиков приложения, как никак Unit Of Work никто не отменял.

Даже в случае с той же Java ЛЮБОЙ запрос в бд синхронен, и не важно сколько асинхронных обвёрток вокруг JDBC налепят - всеравно поток будет блокирован на время выполнения запроса, просто потому что асинхронного JDBC тупо нет в природе. И так сложилось исторически, и это отнюдь не означает что это решение не оптимально и что всё что "блокирует поток" заставляет ваш процессор простаивать, это очень глупый предрассудок дилетантов.

Ну вот к примеру в golang'е достаточно новый и стабильные драйвер lib/pq написан синхронным не потому что это "неоптимально", а просто по привычке и с пониманием того что в ядре ОС тоже есть свой планировщик, и что если нужно то он тоже не будет зря щёлкать процессорные такты, напротив тут приветствуется использование unit of work.

[Viktor Vsk]

KorsaR-ZN: frontender.info/understanding-the-node-js-event-loop
Нода это просто джаваскрипт. Да, есть евент луп, да появляются воркеры. Но никакой чистой асинхронности нет.

[Юрий Ярош]

Виктор Ablebeam: я всегда считал в ноде должен быть какой-то встроенный disruptor, или хотя бы подобие планировщика, сам не ковырялся, но если там действительно такого нет - это просто прискорбно. Hail To the Golang.

[Тимофей]

Есть сервер phusion passenger (возможно, не он один), который запускает одно и то же приложение на ноде в нескольких процессах (можно настроить, чтобы использовались потоки). Грубо говоря, запускаем по процессу на ядро, и считай, что у тебя как будто бы действительно асинхронный JavaScript. Правда, нужно при разработке это учитывать и для данных, которые должны запоминаться между запросами, использовать БД типа redis (при использовании потоков необязательно).

[index0h]

@mr_T
Чем это решение лучше нейтивного https://nodejs.org/api/cluster.html ?

[Тимофей]

index0h: в принципе наверняка многое из того, что есть в passenger, можно реализовать в cluster. А так из того, на что я обратил внимание и что вспомнил (в случае с nginx, с Apache все аналогично в большинстве моментов):
- в passenger все уже реализовано и приложение избавлено от лишнего кода, по сути не относящегося к логике самого приложения;
- настройка в конфигурационном файле nginx (файл логов консоли приложения, использование процессов или потоков, их количество, переменные окружения, балансировка нагрузок и т.д. и т.п.) для каждого приложения отдельно;
- авторестарт сервера при ошибках;
- все возможности nginx (привязка к домену, статика, gzip, rewrite и т.д. и т.п.)
- быстрое взаимодействие nginx с самим приложением за счет использования сокетов вместо портов (сам не знаю, что это, но написано, что так гораздо быстрее :) );
- приложения на ноде не занимают отдельный порт.

[un1t]

Что-то вы перепутали, на IO нода не блокируется.

[index0h]

un1t
www.kennynet.co.uk/2014/07/07/nodejs-and-blocked-io
www.future-processing.pl/blog/on-problems-with-thr...

Пул тредов для эмуляции асинхронности - 4. Если вы читаете 5 больших файлов в асинхронном режиме, 5-ый таки подождет до момента, пока не освободится хотя бы один тред. Подобная штука и с драйверами БД: если драйвер реализовывает собственный обработчик очереди + мультитредовость, а данные отадет через event-loop - тогда имеет смысл говорить про асинхронность, в противном случае: 4 потока, ил тюн libuv.

@mr_T

> настройка в конфигурационном файле nginx
ну, такое. он умеет сетапать прямую отдачу страниц, закешированных в кластере мемкешей?))

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

> все возможности nginx
Да лааадно.

> быстрое взаимодействие nginx с самим приложением за счет использования сокетов вместо портов
Как правило unix sockets быстрее, но отнюдь не всегда, это базовый функционал вебсервера ноды.
https://nodejs.org/api/http.html#http_server_liste...

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

Мда... посмотрел интро у этой штуки, полная хрень. Погуглите puppet, chef, salt, vagrant, docker. Окружение - это неотъемлемая часть приложения. Хотите вы того, или нет - ваш код в абстрактном вакууме работать не будет. Да даже сама нода вместе с npm - это тоже часть окружения.

[Тимофей]

index0h:
Не знаю, я лично memcached так не использовал, но модуль для этих целей в nginx есть. Наверняка его можно использовать вместе с нодой.

Авторестарт (лично на мой взгляд, я не призываю к спору) нужен на продакшене, чтобы приложение тупо не упало, пока спит программист, например. А сами исключения в любом случае попадают в логи и незамеченными не останутся. При разработке, ясное дело, это штука не нужна.

Возможности nginx. Разве нет? Можете сказать, что не работает?

Сокеты и порты. А как связать, скажем, 80 порт с нужным сокетом нужного приложения ноды по домену?

Так passenger разве отнимает возможность взаимодействия с окружением, в котором запускается приложение? Почему в абстрактном вакууме? Приложение работает точно так же, за исключением того, что нет необходимости переписывать код для работы в разных окружениях и конфигурация сервера приложения интегрирована в web-сервер.

Погуглите puppet, chef, salt, vagrant, docker

Погуглил, почитал, что это (не знал о них, спасибо). Опять-таки, непонятно, как может конфликтовать сервер приложения с подобным софтом?

[index0h]

Тимофей

> Не знаю, я лично memcached так не использовал, но модуль для ...
смысл в том, что бы отправлять данные на прямую из мемкэша, без использования ноды, php, python, или на чем там бэкенд написан.

> Возможности nginx. Разве нет? Можете сказать, что не работает?
Я ж вам привел пример с мемкэшем

> Сокеты и порты. А как связать, скажем, 80 порт с нужным сокетом нужного приложения ноды по домену?
Обычно проксируется через nginx на сокет файл + nginx отадет статику. Но это не является обязательным, можно напрямую поднять ноду на 80-м, в таком случае слушать сокет нет необходимости.

> Так passenger разве отнимает возможность взаимодействия с окружением, в котором запускается приложение?
Тебе это не нужно.

> Приложение работает точно так же, за исключением того, что нет необходимости переписывать код для работы в разных окружениях и конфигурация сервера приложения интегрирована в web-сервер.
Если код должен работать на РАЗНЫХ окружениях - он должен таки тестироваться на РАЗНЫХ окружениях)).

> Опять-таки, непонятно, как может конфликтовать сервер приложения с подобным софтом?
Например вы запускаете на старой версии ноды свою апликуху, но используете API последний версии - работать корректно не будет. Либо протвиоположный вариант: используете устаревшее API.

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

[un1t]

index0h: статьи интересные, но я не уверен, что все так как там описано. Во первых вставлять синхронный sleep и делать из этого какие-то выводы, довольно сомнительная штука. Во вторых, я попробовал сам. 100 запросов с mysql (каждый из который выполняется 1 секунду) выполняются меньше двух секунд. Если бы они выполнялись последовательно было бы больше 100 секунд. Вот мой тестовый код pastebin.com/vjt1TQM6

[Фёдор Лапшин]

поддерживаю Golang!

Answer 5

[Viktor Vsk]

10к в день - это не нагрузки. Симфони - явно не хуже джанги или экспресса. Если "тормозит", проставьте индексы в базе и потюнингуйте настройки (в вашем случае, мне кажется, начать хотя бы с pg_tune)

Если и дальше тормозит, то никаких телодвижений, особенно переписывания на неизвестные языки, без профилировщика - узнайте узкие места и задавайте(сь) конкретные вопросы.

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

Comments

[jaxel]

OnYourLips: с чего это вдруг?

[Viktor Vsk]

OnYourLips: все равно не думаю, что это аргумент в пользу того, что б весь проект "переписывать на ноду, питон или плюсы" )

[Фёдор Лапшин]

для CRUD также подойдет Go...

Answer 6

[Mikhail Osher]

Я вас умоляю. Люди на симфони обрабатывают миллиард запросов в неделю.
Грамотно спроектируйте логику, базу данных, кэширование, балансировку - всё будет летать.
И технология не сильно влияет. Главное, это Ваши навыки.

Answer 7

[bromzh]

Выбирай Java

Comments

[Юрий Ярош]

Куча проблем с ржавой: энтерпрайсы глюкают, ORM'ы избыточны до ужаса, из того что есть можно брать netty да JDO на DataNucleus'e и развлекаться, кэшировать где-то в terracotta / hazelcast etc. Для реальных высоконагрузов (4-18M rps 10-40Gbit) часто приходиться прикручивать pfRing / netmap.

[Фёдор Лапшин]

ЦП и ОЗУ от Java очень сильно пострадают или придется иметь кучу серверов/ОЗУ

Answer 8

[Фёдор Лапшин]

Лучше Go!
1. Многопоточен ( использует ядра и потоки, как в NodeJS )
2. Асинхронен
3. Множество либ ( и для инета тоже )
4. Из коробки кучу примочек
5. Кроссплатформенный
6. Компилируемый