Какой язык выбрать под Backend высоконагруженного rest-сервиса?
Задачи бэкэнда - rest-сервис для игр (социальных\мобильных).
Задачи банальные - забрать данный с БД, передать на клиент, получить запрос от клиента, выполнить несложную логику, сохранить в БД, передать ответ.
!!Нагрузка высокая, 150к-300к RPM, создают где-то 30-50к пользователей онлайн - обычное среднее количество для нас. Сейчас все это дело держит PHP в несколько нод. С выходом 7ой версии конечно порадовались, но теперь совсем планируем уйти на компилируемый язык со статической типизацией.
Основная цель - держать как можно больший RPS с ноды.
Краткий обзор чего рассматриваем:
Больше всего нравится GO в плане работы с большим количеством соединений. Goroutines - красота. Но некоторые минусы конкретно убивают плюсы.
С#, вся инфраструктура на Linux, поэтому видимо Mono. Очень много возгласов, что все это не для продакшна.(хотя мы с Mono работаем на клиенте)
С++ - прекрасно, но очень не хочется заниматься самому управлением памяти.
Java - честно говоря - нет опыта, пытались разбираться с потоками: честные потоки явно жрут много оперативки сервера, "дешевые" реализации coroutines пугают тяжелы (можно как-то еще?).
Какой язык(+фреймворк) вы используете для подобных задач и почему?
У нас Go(фрейм.gin-gonic) + mongodb с некоторыми простыми оптимизациями и кешами держит 20-30K соединений в секунду в один инстанс. С fasthttp бенчмарки еще краше, но лень переписывать и излишне оптимизировать. Но вообще в go пришли с nodejs. И go гораздо производительнее и стабильнее.
Ну выбора у вас не много.
Го - на порядки проще, особенно при работе с вашими задачами (http/json/db)
C++ - в разы быстре Го, но и в разы тяжелее вам будет работать с ним
Пока у вас не миллионы онлайна и живёте вы на PHP, спокойно переходите на Go, его хватит надолго.
Ну C++ быстрее Go только на чисто алгоритмических cpu-bound задачах. Раза в 2-3.
На более приземленных вещах, когда у нас еще и syscall и прочие блокирующие вызовы, то тут разницу в скорости еще поискать надо. И на первое место выходит разве что потребление памяти.
p4s8x: ок. значит проблема в архитектуре приложения: много лишних действий.
Например, ряд рекомендаций:
1. При создании структуры для подобных объектов - делать копию и заменять свойства (а не пересоздавать каждый заново).
2. Запросы на выборку можно делать стэком.
3. Часто используемые структуры - наследовать и помещать через менеджер в сокет-сервис.
4. Использовать ===, делать где возможно ставить break в циклах.
5. Никогда не разрывать соединение с базой - использовать сокет-очередь.
Мы из PHP уже выжали все что можно. Мы используем ReactPHP. Сейчас тестируем PHP7, в целом он позволяет сейчас вернуться к объектам, перевести все это в более-менее нормальный ООП и не сильно потерять в производительности относительно себя же. Есть даже статическая типизация, но пока она чаще вредная, чем полезная. Ситуация с void и null пичалит.
p4s8x: "перевести все это в более-менее нормальный ООП" - вот-вот... я об этом и говорю. Кстати, часть вычислительной логики можно передать базе (через запросы или через вызов хранимых процедур).
Голос за C#. Да он не такой быстрый как C++. Но он довольно быстр. Если вы собираетесь выпустить новую версию к лету или позднее можно присмотреться к новому asp.net core mvc. на гитхабе есть бенчмарки(только не смотрите на asp.net mvc 5 он уныл в этом плане). Внизу страницы есть "Plain Text with HTTP Pipelining", как мне кажется очень показательный. Да пока что линукс проседает(при этом все равно оставаясь быстре node.js, который быстрее php), но это дело времени. По поводу того что скала пока что быстрее, два месяца назад asp.net core выдавал в этих тестах 200-300к(на windows). На будущее(год-два) майкрософт пилит компиляцию в нативный код на разных платформах(пока что это работает только на HelloWorld).
300K RPM (5000 qps) можно на любом из предложенных ЯП на одной ноде держать, если аккуратно и с пониманием особенностей выбранного варианта. Ну разве что про C# Mono не уверен.
С учетом ваших задач "сходи туда, обработай ответ, посчитай то, ответь клиенту" выбор Go был бы весьма кстати.
Простой
Средний
