LINUX.ORG.RU

Выбор ЯП для highload rest


0

1

Доброго всем времени суток. Пришла необходимость в создании REST API сервера. Сейчас api на php, но скоро перестанет справляться с нагрузкой. Сейчас смотрю в сторону C++ и libevent (или libhttpd), необходима поддержка ssl, возможно кто то сталкивался с подобным и напишет свое мнение? Сейчас еще вроде модный Go для подобного используют.


На том языке из более менее быстрых, которые знаешь ты и твоя команда. Технически то, что называют Highload вполне может работать на Java, Scala, C++, Go. Но сначала определись, может у тебя тормозом будет архитектура, СУБД, какой-то IO?

vertexua ★★★★★
()

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

entefeed ☆☆☆
()

Максимум можно выжать из С и С++. Лично так «сделал» джавера именно на такой задаче. Но, если ты с этими языками на «вы», то однозначно бери что-то другое, чтоб потом не рвать волосы. И выше правильно сказали - сперва оцени, где у тебя узкое место.

anonymous
()

kPHP жи

Паша Дуров рекомендует

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

Как раз таки с C++ и С хорошо знаком но писал в основном прикладное ПО. Пожалуй именно этим путем и пойду.

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

erlang

Форумный теоретик detected.

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

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

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

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

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

В СouchDB нет кэширования, емнип, данные сразу начинают писаться на диск. Не для хайлода БД писалась, не для него.

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

В СouchDB нет кэширования, емнип, данные сразу начинают писаться на диск.

Если после каждой записи нет fsync (а с ним все было бы вообще печально, так сделано по дефолту в SQLite, например), то кэширование на себя берет ОС.

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

C++

C

Как варианта не хватает Common Lisp.

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

Емнип, то sync там после каждой операции записи.

ТИП, это очень дорогая операция и статистика была бы гораздо хуже.

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

Under normal circumstances, your document is appended to the file, but not sync'ed, along with any other writes from other clients. Within one second, all of those writes are sync'ed and the header is updated.

anonymous
()

А что ты будешь делать, когда твой код на сях/го/whatever перестанет справляться с нагрузкой? Думай сразу про горизонтальное масштабирование.

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

Все лоровские тимлиды пишут сразу гибкий, вертикально и горизонтально масштабируемый код на С/С++, без утечек памяти. Сейчас придет царь и скажет что RPC вообще не нужно, ибо он может на локалхосте на сишечке все посчитать.

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

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

Не стоит передергивать, все зависит от задачи, бывает и так, что действительно проще написать код на С/С++, если используются специфичные библиотеки и требуется максимальная эффективность. Ну, а если весь сервер - просто прослойка между СУБД и пользователем (типичная задача в ынтерпрайзах), то конечно лучше взять, например, Java, тем более, что там это давно отработано чуть ли не до копипасты.

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

Я говорил в рамках конкретного топика, т.е. «highload rest». Вообще, если под задачу есть DSL, то, имхо, его первым делом и нужно попробовать использовать. Если у этого DSL'а есть средства для интеграции с кодом на С/С++ для участков кода со специфическими требованиями: производительность, специфика платформы или задачи, то использовать их (С/С++) в единственном лице не вижу смысла.

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

Вообще, если под задачу есть DSL, то, имхо, его первым делом и нужно попробовать использовать

Видел примеры, как на Java достаточно простую задачу решали именно с помощью готовых по-сути DSL, получали компактное решение, все супер, кроме того, что в секунду обрабатывалось 10-20 запросов. Но не беда - ведь решение уже заранее готово к масштабированию...

Если у этого DSL'а есть средства для интеграции с кодом на С/С++ для участков кода со специфическими требованиями: производительность, специфика платформы или задачи, то использовать их (С/С++) в единственном лице не вижу смысла.

Несомненно, проблема лишь в том, что обычно такие DSL не предназначены «для интеграции с кодом на С/С++», особенно, если на С/C++ организовано хранение и загрузка данных. А использовать, например, Java + tomcat + еще что-нибудь, просто, чтоб заменить библиотеку на плюсах или С, это мягко говоря неразумно и заставит вспоминать тебя самыми нелестными словами.

anonymous
()

Год назад взял бы Go, но сейчас бы не долго раздумывая взял кложуру :-)

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

CouchDB написана на эрланге. Без вставок C, не надо.
https://github.com/apache/couchdb

У вас src отклеился. А если его приклеить назад можно найти:

https://github.com/apache/couchdb/blob/1.6.x/src/couchdb/priv/couch_ejson_com... https://github.com/apache/couchdb/blob/1.6.x/src/ejson/encode.c

и т.п.

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