Бенчмарк RPC систем (и Inverted Json)

[supcry]

> GRPS: вариант для питона

GRPC, исправьте, пожалуйста.

[UnnamedUA]

Не про скорость, а про оверхед, но удобство вопрос тем кто использует NATS: смотрели github.com/liftbridge-io/liftbridge?

[sadko4u]

Об rpc ещё писали в незнамо каких лохматых годах.

С самого начала создания первой сети, Святым Граалем сетевых вычислений было предоставления программных интерфейсов для доступа к удалённым сетевым ресурсам таким же образом, как к локальным. Сеть становится "прозрачной".
Один пример прозрачности сети — знаменитый RPC (удалённый вызов процедур, remote procedure call), система разработанная для того, чтобы вы могли вызывать процедуры (подпрограммы), выполняющиеся на другом компьютере, по сети точно так же, как если бы они выполнялись локально. На это угробили чёртову пропасть энергии.
Звучит логично, правильно?
Неправильно.
Заключение: В следующий раз, когда кто-то попытается продать вам программный продукт, который позволяет вам обращаться к сетевым ресурсам также как к локальным, убегайте как только можете в противоположном направлении.

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

[nicholas_k]

RPC поверх HTTP — ещё большее зло, которое, в принципе, могло придумать человечество

А разве на Хабре не принято обосновывать свою точку зрения фактами и логическими выводами?
Не стоит нарушать монополию религии на нерациональную веру.

[sadko4u]

Конкретные недостатки HTTP, применительно к версии 1.x:
— дикий оверхед по заголовкам и телу сообщения — неэффективное использование трафика;
— отуствие конвейеризации запросов: вы не можете по одному и тому же сокету отправить запросы 1 и 2 на сервер, а ответы получить в обратном порядке — сначала на 2, а потом на 1. Иными словами, сетевой сокет простаивает, когда мог бы заниматься полезной работой.
— На практике редко кто поддерживает персистентные соединения, отсюда имеем оверхед по времени на установление TCP-соединения (TCP handshake) и, если используется SSL, то ещё и на SSL handshake.

Да и, в принципе, всё тот же самый обмен сообщениями можно организовать напрямую через TCP-сокет, без привлечения протокола прикладного уровня, коим является HTTP.

[nicholas_k]

Ну вообще то разговор был о недостатках RPC over HTTP, а не об HTTP как таковом. Ведь RPC так удобно ложится в концепцию «запрос-ответ» без состояния.

Что касается недостатков HTTP то видимо надо убить почти весь интернет. Ну и поубивать все языки более высокого уровня, чем С, потому что оверхэд.

[maxim_ge]

Интересная штуковина! Несколько вопросов возникло:

— Не совсем уловил, как прописываются правила, соединяющие клиентов и обработчиков>
— Может ли быть несколько обработчиков по одной теме?
— Как послать сообщение конкретному обработчику из нескольких?

[lega]

— Не совсем уловил, как прописываются правила, соединяющие клиентов и обработчиков>

Есть 2 варианта, один описан в 5 разделе — например если обработчик должен обрабатывать команду «start», обработчик отправляет серверу json: '{"name": "start"}' и после того как клиент отправит запрос на url /start, клиент и обработчик будут «соединены» (но только на 1 команду т.к. вторая команда от клиента может быть другая на другой обработчик).
Для второго варианта пример тут, так же есть несколько примеров тут.

— Может ли быть несколько обработчиков по одной теме?

Да, множество обрабочтиков и множество клиентов на одни и теже «темы» (очереди) работают хорошо.

— Как послать сообщение конкретному обработчику из нескольких?

Для этого обрабочик может добавить список команд которые могут содержать идентификатор, например '{"name": "start:15,start"}', таким образом обработчик одновременно обслуживает 2 команды «start:15» и «start» (где 15 — это идентификатор). А клиенты в свою очередь могут получить список всех обработчиков из "/rpc/details" и работать с выбраным (подобный подход так же используется и для MQ систем).

[lega]

Обновлю коммент, т.к. некоторые моменты стали проще.

Не совсем уловил, как прописываются правила, соединяющие клиентов и обработчиков

Теперь нужно просто задать тот же url для клиента и обработчика, пример:
Клиент:

curl localhost:8001/calc/sum -d '{"data": "data"}'

Воркер:

curl localhost:8001/calc/sum -H 'type: get'

Разница в том что для воркера нужно указать header «type: get» — что значит «взять задачу».

— Как послать сообщение конкретному обработчику из нескольких?

Для этого можно просто указать id воркера в headers, пример:

curl localhost:8001/calc/sum -H 'worker-id: 15'

[bat]

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

зы
envoy не пробовали?

[lega]

Следовало бы так же протестировать все компоненты на разных хостах

Изначально тест и проводился на разных хостах (в Digital Ocean), но видимо там сеть была не быстрая и многие тесты показывали одинаковый* результат, но мы тестируем не скорость сети, а сервер/прокси, поэтому было решено тестировать без влияния сети (ведь у всех разные сети).

grpc, если клиент на столько неэффективен, следовало бы его исключить.

Мне кажется это может быть полезной информацией для питон разработчиков, чтобы потом не удивлятся когда GRPC будет уже внедрен.

envoy не пробовали?

Нет, но возможно в следующий тест будет включён.

[bat]

сделал тот же тест GRPC на Go
Intel® Core(TM) i5-4670 CPU @ 3.40GHz (ксеонов нема)
получилось от 9000 rps для одной клиентской горутины до 90000 rps для 50 горутин

[lega]

Да, как я и упомянул, для компиллируемых языков той проблемы быть не должно и GRPC должен быть быстр, не поделитесь исходником?, тоже интересно потестить.

[bat]

в личке

[Master_Dante]

Простите но это значит что GRPC на 20% быстрее вашего решения, а вы использовали паносный язык специально что бы это сокрыть.

[lega]

но это значит что GRPC на 20% быстрее вашего решения

1. Не значит, тестовые конфигурации разные.
2. Это не особо важно, т.к. «инструмент под задачу».

а вы использовали паносный язык специально что бы это сокрыть

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

И этот тест как раз полезен для разрабочиков python, чтобы было меньше удивления от низкой производительности использования grpc в python. А про другие языки в статье упомянуто.

[posledam]

Если Python используется исключительно как простейший прикладной интерфейс, какой смысл вообще писать "на Python"? Например, библиотека для работы с gRPC в .NET написана 100% на .NET, работает так же быстро как библиотека на Go.

Но, получается вы пишите про протоколы, а сравниваете какие-то библиотеки, при чём через прокладку на Python-е. Как будто это имеет это имеет какое-то отношение к нему.

Очень странные бенчмарки, не заявлена какая задача решалась, и зачем всё это было.