LINUX.ORG.RU

Выбора тред: Node.js vs Go

 ,


1

5

Дорогой ЛОР, помоги выбрать.

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

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

Написано все это дело на good old php + laravel, потестировав это дело под нагрузкой я остался не доволен, учитывая что мне потом понадобится мобильное приложение которое будет работать с API, все это дело выйдет в копеечку, да и response time как-то не очень, даже если это дело все оптимизировать я улучшу результат в 2-5 раз, но это все равно мало.

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

Под мои задачи подходят Node.js и Golang, что выбрать? что лучше? по результатам моих тестов предположительно подходят оба.

Не предлагать:
Ruby, Python - производительность будет такой же.
Java, Scala - оставьте это банкам, скорость разработки слишком низкая, IDE на Java тормозят.
C# - тут все понятно, мне он импонирует, вот только он от MS, MSVS тормозит и только под оффтопиком.
Ну и всякую другую полудохлую минорщину.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Написано все это дело на good old php + laravel, потестировав это дело под нагрузкой я остался не доволен, учитывая что мне потом понадобится мобильное приложение которое будет работать с API, все это дело выйдет в копеечку, да и response time как-то не очень, даже если это дело все оптимизировать я улучшу результат в 2-5 раз, но это все равно мало.

Открой для себя кеширование.
В ноде от организации логики(особенно если она сложная) у тебя попка порвётся. Оно для простеньких API получил запрос -> отдал данные.

ritsufag ★★★★★
()
Ответ на: комментарий от ritsufag

Открой для себя кеширование

Открыл, мне кеш генерировать каждые 5 минут для каждого пользователя индивидуально?

ноде от организации логики(особенно если она сложная) у тебя попка порвётся. Оно для простеньких API получил запрос -> отдал данные.

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

umren ★★★★★
() автор топика
Последнее исправление: umren (всего исправлений: 1)
Ответ на: комментарий от umren

Кэшировать байткод(OPcache искаропки). Данные для каждого пользователя тоже можно, хотя зависит от частоты обновления и объёма данных(в memcached бывает накладно держать). К тому же если в приложении упор на взаимодействи с БД, то чёрт возьми причём тут вообще php? Оно будет так же тормозить и с шарпом и другими компилируемыми ЯП.

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

Ты собираешься писать синхронный код?

ritsufag ★★★★★
()
Последнее исправление: ritsufag (всего исправлений: 2)
Ответ на: комментарий от umren

Ну почему же сразу ноду.
У меня просто подозрение что дело в Вас самих, нежели в php и laravel.

SANSLAR ★★
()
Ответ на: комментарий от ritsufag

Ты собираешься писать синхронный код?

В том числе, можете описать типичную бизнес логику с которой у вас проблемы в node.js?

umren ★★★★★
() автор топика

Субъективно

Мы вполне успешно переписываем нагруженный проект с node.js на Go: не мыслимо представить — по какой повестке, в пределах общего случая, разумным было бы противопоставить эти два языка (две платформы), чтобы в выигрыше оказался node.js. Мы в общем-то таковой не усмотрели, и решили вопрос известным образом.

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

Моё слово за исключительность Go

petushok
()
Ответ на: комментарий от ya-betmen

Хотите делать на ноде - вперёд, но какой смысл спрашивать если не случать, что отвечают?

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

umren ★★★★★
() автор топика

Ладно парни, расходимся, сделал сегодня первые наброски похожего приложения на node.js - говно говном, а Go мне кажется еще не «готов», оставлю этот проект на теплом ламповом пэхапэ, буду тюнить значит

umren ★★★★★
() автор топика
Ответ на: комментарий от Miguel

не парься, не видишь что ли, парень умных слов нахватался, решил блеснуть, видать вдохновение после «программист vs админ» ещё не прошло.

anonymous
()

Java, Scala - оставьте это банкам, скорость разработки слишком низкая

Ты или вопрос задавай, или вбрасывай.

anonymous
()
Ответ на: комментарий от umren

Только во влажных фантазиях нодеров.

bj
()
Ответ на: комментарий от anonymous

Потому что ТС неосилятор.. Го давно взлетел, в проде уже 2 года

expelled ★★
()
Ответ на: комментарий от anonymous

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

anonymous
()

Бери Golang конечно-же. Про Scala/Play действительно пора давно все забыть. Скорость разработки на нем нулевая, с учетом постоянной компиляции scala templates и прочего уг. Если TypeSafe перестанет в Play вливать деньги, то он сдуется сам по себе через 2-3 года.

abc
()
5 сентября 2014 г.
Ответ на: комментарий от umren

А теперь попробуй доказать, что моё предложение смешит тапки, и испытай баттхёрт от того, что при всей уродливости крестов лучших альтернатив, в общем-то, и нет.

Lavir_the_Whiolet
()

по названию подумал, что это троллинг на тему /https://news.ycombinator.com/item?id=7987146

zarkone ★★
()

Хочешь выжать максимум из языка - Java. Остальное на порядки медленней. Но в твоём случае тормоза не в языке и смена PHP на whatever ничего не изменит, так что выбирай что угодно, на скорость это не повлияет

Legioner ★★★★★
()
Ответ на: комментарий от Lavir_the_Whiolet

Хватит некротредить, кресты для веба не подходят, вообще никак и ты САМ это знаешь.

umren ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Хочешь выжать максимум из языка - Java

на Java EE писать? фреймворков то нормальных нет

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

Servlet + JSP - очень высокопроизводительная связка. Как вариант - Netty, но это будет достаточно низкоуровнево, хоть и порвёт всё, кроме, разве что, оптимизированного С/С++.

Legioner ★★★★★
()
Ответ на: комментарий от umren

как и сам инструмент что ли?

Нет, не так. Инструмент нужен, а «зрелый mvc фреймворк» для него - нет.

Debasher ★★★★★
()
Ответ на: комментарий от Legioner

Servlet + JSP - очень высокопроизводительная связка

Знаю, но если нужно будет именно такое, то лучше уж Go хоть он и будет в раза ~2 помедленней.

umren ★★★★★
() автор топика

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

Как ты вообще работаешь с данными? Собираешь раз в час все события по рсс с других сайтов и рассылаешь письма пользователям? Или может ты просто имеешь веб-приложение, что по аяксу долбит и выдаёт свежую инфу? Или хранишь в бд все записи о выходах альбовом и по запросу просто выдаёшь все данные?

Фреймворк ЛЮБОЙ подойдёт - главное чтобы ты в нём не утонул, пока будешь изучать. У ноды только плюс - вебсокеты «искаропки» и без особых шаманств.

Опиши что там у тебя происходит на бекенде, может подскажу что.

tia
()
Ответ на: комментарий от tia

Как ты вообще работаешь с данными? Собираешь раз в час все события по рсс с других сайтов и рассылаешь письма пользователям?

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

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

т.е. кешировать бд не вариант.

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

Кешировать будет накладнее отдачи напрямую из БД. У каждого юзера уникальный набор данных. Зачем мне прослойка в виде кеша на каждого?

umren ★★★★★
() автор топика
Последнее исправление: umren (всего исправлений: 1)
Ответ на: комментарий от umren

Как зачем - для скорости? У тебя данные каждую секунду меняются? Если нет, то кеш ускорит выдачу в несколько раз и запрос не пойдет в БД ведь.

duck
()
Ответ на: комментарий от umren

Окей.
Значит у тебя есть таблица с подписками и таблица с веб-оповещениями.
Для сбора данных тебе нужен процесс в бекграунде - можешь хоть на сях написать, его задача - взять данные из подписок, запросить из АПИ и протолкнуть результат в оповещения. Такую фишку можно писать хоть на чём, но из соображений того, что ты юзаешь вызовы к АПИ, то встаёт мысль о том, что стоит применить асинхронщину - нода для такого была и создана. Посмотри в сторону Kue.

Далее, если предположить что это две таблицы в БД, то дела плохи, узкое место - БД. Можно иметь по таблице на юзера, а можно - подумать использовать другие БД. Как вариант, взять монгу и пихать нотификации в один докемент, ассоциированный с юзером. Размер дока - 16мб, хватит за глаза, если будешь хранить ссылку, название, ещё что.
Но тебе в любом случае нужно будет хранить всю это инфу долгое время, чтобы даже после получения уведомления, человек мог увидеть какие последние альбомы вышли, так?
Тогда имеет смысл хранить большую бд альбомов, которую пополнять из АПИ - это будет практично для случаев, когда человек подписался и альбом вышел пару дней назад - юзеру надо это сказать.

Затем сам веб-интерфейс. По сути, тебе нужно показать просто накопленные нотификации и N последних альбомов по выбранным группам/жанрам. Узкое место - только БД.

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

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

tia
()
Ответ на: комментарий от umren

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

tia
()
Ответ на: комментарий от tia

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

так и происходит конечно, уже :)

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

выйгрыша по сравнению даже с быхлопхп в этой задаче не будет почти вообще

Но тебе в любом случае нужно будет хранить всю это инфу долгое время, чтобы даже после получения уведомления, человек мог увидеть какие последние альбомы вышли, так?

Да, уведомления это одна из фишек (главных), но посмотреть тоже все можно.

Про нотификации думаю забудь, группы не в реалтайме выпускают альбомы.

раз в несколько часов достаточно, в крайнем случае раз в 24 часа, с сериалами критичней время ) с музыкой не так уж.

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

Да я согласен, узкое место БД.

umren ★★★★★
() автор топика
Ответ на: комментарий от duck

Как зачем - для скорости? У тебя данные каждую секунду меняются? Если нет, то кеш ускорит выдачу в несколько раз и запрос не пойдет в БД ведь.

Эм, представь что у тебя есть N групп, каждый юзер подписан на разные группы, 1000 юзеров смотрят списки, все это фигачится из БД конечно, каждый юзер может подписатся на произвольный набор групп из этих N. Может я совсем тупой, но как ты будешь склеивать весь этот кеш из 1000 нагенерированых? И не будет ли это накладнее, чем просто позвать из базы? Кеш не всегда применим.

umren ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.