Redis устанавливает проблему производительности - PullRequest
0 голосов
/ 08 сентября 2018

Я пытаюсь сравнить мою команду redis SUNION. Во время бенчмаркинга один из наборов содержит ~ 1000 элементов, а другой - ~ 10 элементов.

Порядок выполнения составляет около 0,52 мс на вызов.

Является ли эта производительность идеальной, или мне не хватает некоторых настроек в файле conf.

Я пытаюсь реализовать фильтрацию тегов на объектах с помощью операций с базовыми наборами. Например obj1 -> {id - 1 colour red location x}

obj1 -> {id - 1 colour red location x} obj2 -> { id - 2 colour yellow location y} obj3 -> { id - 3 clolour red location y}

Для хранения я использую наборы для хранения идентификаторов объектов для каждого измерения. Затем

colour:red -> {1,3} colour:yellow -> {2} location:x -> {1} location:y -> {2,3}

Это позволяет мне выставить apis поверх этого как: объекты окрашены в красный цвет в месте х объекты, окрашенные в красный цвет в любом месте

каждая из них на самом деле переводится в несколько операций над множествами для меня, используя разность пересечения объединений, которую я реализовал с использованием конвейеров.

Масштаб: Максимальное количество элементов внутри любого набора очень меньше ~ 5000. И задержка является основным моментом. Если есть какой-то другой способ, которым я должен пойти, чтобы достичь такого рода производительности. Было бы полезно.

1 Ответ

0 голосов
/ 09 сентября 2018

Я не знаю, является ли производительность идеальной (звучит отлично, менее 1 мс - это здорово в моей книге, но это действительно зависит от ваших требований).

Я выполнил следующий тест на своем ноутбуке:

$ for i in `seq 0 999`; do redis-cli sadd s1000 forbar$i; done
...
$ for i in `seq 0 9`; do redis-cli sadd s10 foobar$i; done
...
$ redis-benchmark SUNION s1000 s10
...
100.00% <= 56 milliseconds
1171.37 requests per second
$ redis-benchmark SUNION s1000
...
100.00% <= 57 milliseconds
1062.70 requests per second
$ redis-benchmark SMEMBERS s1000
100.00% <= 19 milliseconds
3300.33 requests per second
$ redis-benchmark SINTER s1000
100.00% <= 17 milliseconds
3311.26 requests per second

...

127.0.0.1:6379> INFO
# Server
redis_version:999.999.999
redis_git_sha1:4e5e0d37
redis_git_dirty:1
redis_build_id:abfc1e37fd7acbf7
redis_mode:standalone
os:Darwin 17.7.0 x86_64
arch_bits:64
multiplexing_api:kqueue
atomicvar_api:atomic-builtin
gcc_version:4.2.1
process_id:23596
run_id:73b0f2f6795eccb8286fc086c83d89da45314ce2
tcp_port:6379
uptime_in_seconds:55429
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:9775394

...

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro11,4
  Processor Name:   Intel Core i7
  Processor Speed:  2.2 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB
  Boot ROM Version: MBP114.0184.B00
  SMC Version (system): 2.29f24

Эти результаты (и некоторые копания в коде) показывают, что:

  1. SUNION медленнее, чем просто получение членов набора (SMEMBERS использует ту же реализацию, что и SINTER).
  2. Итерация и ответ с 1000 элементами занимает не менее 17-19мс
  3. Разница между SUNION и другими не в порядках, что хорошо, но, возможно, требует некоторой оптимизации в коде Redis (по крайней мере, для этого крайнего случая).
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...