RedisPipe — вместе веселее

[youROCK]

Обидно, что выигрыш по CPU на клиенте начинается только от очень большого QPS на конкретный сервер. Учитывая, что зачастую серверов с кешом сильно больше одного и они шардированы, с каждого клиента получается не такой большой QPS, и суммарного выигрыша по CPU, вероятно, не будет.

[funny_falcon]

Да. Но с другой стороны, редко данные, пришедшие с редиса, не подвергаются десериализации. И на её фоне небольшие потери не заметны.
Зато экономия ЦПУ на серверах Redis становится заметной довольно скоро.

[funny_falcon]

В теории, можно динамически реагировать на RPS, и выключать паузу, если RPS низкий. С выключенной паузой потребление CPU клиентом примерно равно классическому коннектору.
Я только не придумал еще, как это красиво сделать, да и нужно ли.

[ZurgInq]

Не совсем понял, как работает pipelining со стороны сервера. Выигрыш в производительности возникает на том, что к моменту вызова epoll на стороне сервера, уже скопилась пачка запросов и он их выгребаются скопом, а не по одному? Но ведь тоже самое должно случится и в том случае, если много клиентов пишут быстрее чем сервер обрабатывает одиночный запрос и накапливается очередь запросов.
И видимо редис тоже буферизует ответы и по возможности отправляет их пачкой?

[funny_falcon]

Несколько моментов:
— во-первых, на каждый приходящий пакет внутри операционки происходит ряд нетривиальных действий (я постарался их описать в начале статьи). Соответственно, чем меньше пакетов приходит, тем меньше работы на уровне операционной системы.
Так как количество запросов неизменно, кол-во пакетом можно уменьшить только собирая запросы вместе.
— во-вторых, epoll только сообщает, что из сокета можно прочитать. А после их ещё оттуда нужно прочитать. Если запросы пришли в один сокет, скорее всего это будет один read. Если же побились по одному запросу на сокет, то вызовов read будет много.
А вызов read — это не только «скопировать данные». Ещё нужно пометить буфер пустым. А раз мы пользуемся epoll, то это ещё и «убрать этот сокет из списка готовых к чтению для этого epollfd». В общем, вроде действий немного, но если приходится делать их часто, но набирается заметно.
— ну и в-третьих, да, ты прав, редис тоже буферизирует ответы и отправляет их пачкой. И все бенефиты повторяются в обратном направлении.

[neenik]

Но ведь и в go-redis/redis и в redigo есть пайплайнинг. И он там очень давно есть.

[funny_falcon]

Все коннекторы redis предоставляют возможность ЯВНОГО пайплайнинга: программисту нужно накопить пачку запросов; сказать коннектору, что сейчас будет пайплайнинг; скормить пачку запросов; сказать, что пачка закончилась; подождать результатов.

Вся проблема в том, что в одном "потоке вычисления" (читай: в горутине) редко такая пачка случается. Много запросов уходит в редис по одному. Потому я и заморочился над неявным пайплайнингом, чтобы собирать запросы с независимых друг от друга горутин.