Какой выбрать язык для серверной части 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

[un1t]

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

Answer 1

[xmoonlight]

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

Comments

[Komly]

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

Answer 2

[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 3

[index0h]

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

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

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

Comments

[KorsaR-ZN]

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

[Viktor Vsk]

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

[Тимофей]

Есть сервер 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 4

[Viktor Vsk]

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

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

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

Comments

[jaxel]

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

[Viktor Vsk]

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

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

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

Answer 5

[Mikhail Osher]

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

Answer 6

[bromzh]

Выбирай Java

Comments

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

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

Answer 7

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

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