Что производительнее Go или Erlang?

Question

[M L]

Сейчас весь код написан на PHP.
И как мне изначально было понятно, что производительность у него так себе. Даже 7 ветка не спасала.
Теперь стоит выбор между очень крутыми языками GO и Erlang.
Погуглив было не понятно. 50/50
И статьи были написаны около двух лет назад.
Какой язык программирования лидирует в плане нагрузки и обработки процессов?

Comments

[sim3x]

какой тип хайлоада?

[M L]

sim3x: в смысле?

[sim3x]

Michael Landau: в прямом. Какого типа нагрузка идет на железо?

[M L]

sim3x: 10000~ запросов в секунду.

[sim3x]

Michael Landau: каких запросов?
на чтение, на запись, на обновление, на перенаправление потока
просто сайт, видео, медиа, статика
сколько серверов
...

[M L]

sim3x: какое отношение это к вопросу имеет? Приложение растет. На 400~ запросов в 3 дня.
В основном запросы на чтение 8000~ (проверка аутентификации получение постов, фотографий и т.п.) Около 2000~ запросов на запись. Два сервера.

[sim3x]

Michael Landau:
Какое отношение?
Прямое. Как можно что-то оптимизировать, если непонятно, даст ли новый код прирост производительности

Мы говорим про RPS (requests per second)?

[M L]

sim3x: да.
Сейчас написано очень много кода.
Сразу переписать код на GOlang/ERlang не удастся.
Возможна частичная реализация некоторых функции приложения через API.
Сразу будет виден прирост производительности.
Вопрос у меня какой язык на сегодняшний день лидирует в плане производительности?

[sim3x]

Michael Landau: Лидирует - ASM, С
Для обработки чатиков - ерланг
golang альтернативf для "я люблю писать на питоне, но он медленный"

В зависимости от того куда движення приложение вцелом, стоит думать как его переписывать

Ерланг, вчасности, может заменить nginx на фронте и ето поможет, если медиа нужно отдавать с хитрой авторизацией

Сейчас, тебе нужно подумать, как расчленить приложение, чтоб его можно было масштабировать добавляя сервера, а не переписывая код

Те серебрянной пули - нет
Напиши нагрузочные тесты и сделай два аппа на го и на ерланге и решай, что лучше

[M L]

sim3x: вот именно что масштабировать все можно, но прибыль пока еще не покрывает затраты.
Поэтому мне сейчас нужно, что-то крутое, чтобы в скором времени все не упало.
Прочитал эту статью https://habrahabr.ru/post/172795/ и начал интересоваться.
Еще где-то слышал, что erlang держит 4 000 000 одновременных подключений, nodejs 1 000 000,
а про PHP c его реализацией всего 7 000. И это логично.

[sim3x]

Michael Landau:
*активных подключений
Для АПИ не нужны активные соединения

Для уменьшения нагрузки нужно, чтоб пользователи чаще пользовались своим кешем, а не обращались к тебе. Или обращались к другим сервисам, которые обслуживают запросы дешевлем чем стоит твое железо

Те SPA с хорошим кеширование даст серьезное падение нагрузки, для постоянных пользователей

Еще раз.
Тебе нужно произвести инвентаризацию нагрузки.
Пока ты не знаешь, что тормозит - не трогай код вообще

[M L]

sim3x: да ничего пока не тормозит. Просто скоро пойдут эти длинны очереди PHP.
А вскоре падения вовсе.
Код большой но оптимизированный. Api реализация отдельного кода на Erlang/Goland (минуя интерпретатор PHP). Просто переписать весь код будет сложно. Потом только сидеть и баги править. Уж легче собственный интерпретатор PHP написать.

[sim3x]

Michael Landau: не тормозит? Добавь нагрузки, когда упрешься в ресурс цпу/рам/ио, добавь еще. Посмотри как умирает приложение

И смотри, где нужно твое внимание
Если у тебя есть навыки для переписывания всего интерпритатора пхп ,а потом его поддержки - дерзай

[Mikhail Osher]

У Вас нет понимания того, что не от языка тут всё зависит. Зависит архитектуры, распределения, знаний в области масштабирования и поиска узких мест.

Производительности PHP более чем достаточно, чтобы принять запрос и отдать ответ.
В любом раскладе потребуется горизонтальное масшитабирование, кластеры, CDN, varnish, load balancing.
Прикручиваете мониторинг, находите боттлнеки. Зачастую, одним из узких мест являются следующие "ошибки:
- отдача статики тем же сервером, который принимает запрос на бэкенд - нужно вынести статику отдельно
- переполнение основного потока лишними задачами: часть из них можно (а зачастую нужно) вынести в воркеры, и как можно быстрее отдать респонс клиенту
- если используется ActiveRecord - выкинуть его, переписать на DataMapper/QueryBuilder
- кэширование на уровне HTTP и базы данных тоже необходимо. Redis просто musthave в данных случаях

[M L]

Mikhail Osher: Две одинаковые функции. Одна на PHP другая на Erlang.
Оба языка передают сообщения через сокеты.
10000~ клиентов. Скорость работы 0.3s на полную загрузку страницы. Все круто.
PHP на это надо 2 сервера. Erlang с одним серваком справится.
Я к тому, что можно все масштабировать, вылезать код на PHP. Но он не сравниться со скорость работы Erlang.
Вот именно, что PHP хватит производительности, чтобы отдать страницу 1-7к пользователей.
Но Erlang, может во много раз больше продержать.

Answer 1

[Maxim Sokhatsky]

Если задача померяться с пацанами в ЖЖ цифрами и продемонстрировать что ты быстрее эрланга на 5-10% — то Го. Если ты хочешь более-менее фунциональный веб, то Erlang конечно. Но на Го так быстро слепить бенчмарк для веб, который нагнет Erlang не так то просто.

Answer 2

[Сергей]

В числодробилках Go побеждает.
https://benchmarksgame.alioth.debian.org/u64q/comp...

в более реальных кейсах я думаю одинаково.

В общем надо исходить того что вам нужно.
Если легко и не принужденно работать множить задачи на все ядра проца + перекладывать байтики из одного сокета в другой, то Erlang в самый раз. Насчет Golang сказать не могу, не использовал.
Сам практикую Erlang уже 5ый год. Доволен.
с PHP сравнивать смысла нет.

Comments

[Илья]

Пишущих на го ещё можно найти. Erlang здесь полностью проигрывает.

[M L]

Илья: это ваше мнение

[Илья]

Michael Landau: какое мнение? Это видно невооруженным взглядом и по вакансиям, и по гитхабу.

[M L]

Илья: видимо у Вас взгляд совсем не вооруженный.

Answer 3

[lega]

Даже 7 ветка не спасала.

Для каких задач? Выясните сначала в чем проблемы.
Гигантский facebook работал (работает) на php, так что его вполне может хватить при правильном использовании.

Comments

[M L]

О чем Вы? Каком нахрен PHP? Тама HHVM Это собственный компилируемый язык по синтаксису очень похож на PHP, но у него есть преимущество async/await + язык программирования HACK

[M L]

Плюс собственная реализация JIT компиляции.

[M L]

И с чего Вы взяли, что у facebook даже при таком раскладе нет проблем?

[lega]

Michael Landau: > Каком нахрен PHP?

т.е. вы утверждаете что fb никогда на php не работал?

[M L]

lega: мы про сегодня говорим? Смысл вообще было писать этот ответ. И в fb есть Erlang, если про его инфраструктуру почитаете, а не будете писать ответы от балды.
И еще немного.
Facebook был реализован в 2004 изначально для студентов меж колледжей.
То есть изначально никто не думал, что у них будет 2млрд. пользователей.
На PHP код написать намного быстрее, чем на низкоуровневых языках.
Но я так понял Вы не знаете как устроен этот язык внутри.

[lega]

Michael Landau: Вы не правильно поняли,
рабочий HHVM появился всего несколько лет назад, до этого много php работало в fb, при этом у них уже были сотни миллионов пользователей.

Я к тому что если руки прямые то и на php можно большую нагрузку держать.
А если у вас руки кривые, то вам и с++ не поможет.

[M L]

Блин меня бомбит от твоих ответов.
Ты понимаешь как PHP работает с памятью?
Если ты напишешь код с макс. оптимизацией на php, его все равно сделает nodeJS, тем более Erland.
И вот у тебя этот твой крутой код на PHP и сервер. К тебе двинулось море пользователей.
Потихоньку твой мега быстрый код начинает проседать.
Да так проседать, что пользователь думает, что у него интернет выключили.
Это логично потому, что PHP не поддерживает много-поточность, знал бы ты как у него очистка мусора устроена. И хрен бы с этим. У него нет как выше упомянуто даже async/await.
И не надо коверкать опять мой текст, я сейчас про чистый PHP говорю https://php.net, хотя его даже это бы не спасло, как и ruby на высокой нагрузке.
Тут на помощь тебе, только серверное кэширование php.
При таком раскладе твой мега-крутой код выдержит 7к активных подключений в секунду.
Твои ответы только других людей в заблуждения вводят.
Сейчас мне нужна бизнес-логика, от тебя я ее не услышал. Ты начал только убивать меня своими знаниями.

[lega]

Michael Landau: > Блин меня бомбит от твоих ответов.
Медитируй, может полегчает.

Переведу тред в мир медиков:

Пациент приходит к доктору,
Пациент: Какую мне таблетку съесть, синюю (erlang) или красную (go)
Доктор: А что у вас болит? (Нужно выяснить сначала в чем проблемы.)
Пациент: бла бла бла космос, корабли бла бла бла
Доктор: А болит то что? В чем проблемы?
Пациент: ААА, меня от тебя бомбит...

> При таком раскладе твой мега-крутой код выдержит 7к активных подключений в секунду.
А тебе сколько надо? в среднем это в 100 раз больше чем весь stackoverflow держит.

[M L]

lega: у тебя прямая дорога на /dev/null. А за шутку про stackoverflow посмеялся.

[Никита]

lega: highscalability.com/blog/2014/7/21/stackoverflow-u...
Сейчас врятли посещения упали до 70/sec

[lega]

Никита: вот более точные цифры: https://www.quantcast.com/stackoverflow.com#/traff...
5,5М в сутки, 5500000÷24÷60÷60 = 64rps в среднем.

[Никита]

lega: facepalm, вы что посчитали? Такого равномерного посещения даже в тестах сложно оформить

[lega]

Никита: > Такого равномерного посещения

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

[Никита]

lega: среднее в этой сфере!= среднее арифметическое всего и вся. А лучше просто забейте, я понял что вам не понять.