Сразу к сути
redis-benchmark на сервере показывает ~120к set/get операций в секунду, что меня устраивает.
при тесте php5.6 + redis
100000 итераций
lrang name 0 -1
- Выполняется ~7 секунд...
Если оформить все в одну большую транзакцию(pipeline) то около ~0.6 секунды... что дает прирост x10 скорости, но одна большая транзакция мне не нравится.
версия redis-server 3.0.6 (конфиг по умолчанию).
версия php-redis (3.1.2-1+deb.sury.org~xenial+1).
К сожалению на одного пользователя может приходится до 10кк(но в среднем не более 50к) задач в день. Те пользователь присылает набор данных и есть несколько задач растянутых во времени таких как, определения к какому из не пересекающихся диапазонов натуральных чисел относится то или иное число.
Основной признак, что большинство вычислений отложенные, но выполняются десятками consumerов(получающих задачи в rabbitMQ) и других скриптов.
Те я раздумываю над тем что бы те данные которые сейчас постоянно запрашиваются с диска, хранить in memory, а желательно еще и вычислять "In memory". приведенный пример поиска к какому диапазону принадлежит число и необходимая информация о диапазоне, прекрасно забирается средствами radis в 2 команды; и редис умеет это делать быстро. но 7000 в секунду - это крайне мало, 70000 которые получаются с транзакций мне нравятся больше.
Fortop, Нет, но это не боевая задача (она давно решена построением дерева при старте скрипта, может не сильно оптимально), я ее просто выбрал для теста производительности связки php+redis. и как мне кажется в этой связке очень большое time latency. внутренние тесты редиса говорят, что latency измеряется в каких-то микроскопических значениях. Это совсем не хорошо тратить значительно больше времени на передачу данных, чем на их выборку.
Эта задача да академическая (я хочу понять, что можно выжать из этой связки). Т.к. в планах внедрить кэширование части данных в редисе. и мне казалось, что сервер с redis даст много экономии времени на чтении данных с диска. Но 7000 запросов в секунду на один поток, не выглядит впечатляющей скоростью. конечно прежде чем посыпать голову пеплом, нужно сравнить скорость с аналогичными запросами к mysql. И сравнить скорость со связкой go+redis;