Redis - увеличивается время set () после 300 т. ключей

Здравствуйте. Работает парсер, пишет в редис. На момент добавления 300 000 ключей (согласно info, сам размер rdb 27 MB) увидел что время на запись ключа стало не 0.001 как при пустой БД, а 0.08, что существенно увеличило время выполнения моего синхронного скрипта.

Так вот меня удивляет этот факт. Конфиг редиса стандартный. ОП памяти 16GB на машине, 8 ядер процессор. Тестирую парсер на виндовс 7.

Разве так и должно быть?

Я, конечно, могу посмотреть в сторону асинхронности, многопоточности либо задействовать NodeJS, но может можно как-то иначе решить этот вопрос. Буду благодарен за идеи.

 

Конфиг прикрепил. Там есть возможность убрать периодическую запись в файл БД (экспорт данных к дамп), добавить мэмори лимит и т.д. После плясок с конфигом особо ничего не поменялось.

 

Записи максимум по 100 символов, по сути json строка. В среднем длина около 30 символов. Пробовал ставить memory limit 10 ГБ так так память позволяет. Не помогло. Поэтому вряд-ли бросает. Тем более в редис инфо написано [used_memory_peak_human] => 62.29M. Я подключаюсь напрямую без редиски.

 

Вот полный редис-инфо:

Array
(
[redis_version] => 3.0.501
[redis_git_sha1] => 0
[redis_git_dirty] => 0
[redis_build_id] => ba05b51e58eb9205
[redis_mode] => standalone
[os] => Windows
[arch_bits] => 64
[multiplexing_api] => WinSock_IOCP
[process_id] => 2928
[run_id] => 078292439f7dee97f77d0e7f885de8fdf57a1d85
[tcp_port] => 6379
[uptime_in_seconds] => 6029
[uptime_in_days] => 0
[hz] => 10
[lru_clock] => 13360558
[config_file] => d:\openserver\modules\redis\Redis-3.0-x64\redis.conf
[connected_clients] => 1
[client_longest_output_list] => 0
[client_biggest_input_buf] => 0
[blocked_clients] => 0
[used_memory] => 63280688
[used_memory_human] => 60.35M
[used_memory_rss] => 63222040
[used_memory_peak] => 65320216
[used_memory_peak_human] => 62.29M
[used_memory_lua] => 36864
[mem_fragmentation_ratio] => 1.00
[mem_allocator] => jemalloc-3.6.0
[loading] => 0
[rdb_changes_since_last_save] => 0
[rdb_bgsave_in_progress] => 0
[rdb_last_save_time] => 1472972321
[rdb_last_bgsave_status] => ok
[rdb_last_bgsave_time_sec] => -1
[rdb_current_bgsave_time_sec] => -1
[aof_enabled] => 0
[aof_rewrite_in_progress] => 0
[aof_rewrite_scheduled] => 0
[aof_last_rewrite_time_sec] => -1
[aof_current_rewrite_time_sec] => -1
[aof_last_bgrewrite_status] => ok
[aof_last_write_status] => ok
[total_connections_received] => 20
[total_commands_processed] => 352968
[instantaneous_ops_per_sec] => 0
[total_net_input_bytes] => 15868781
[total_net_output_bytes] => 24437111
[instantaneous_input_kbps] => 0.01
[instantaneous_output_kbps] => 1.21
[rejected_connections] => 0
[sync_full] => 0
[sync_partial_ok] => 0
[sync_partial_err] => 0
[expired_keys] => 0
[evicted_keys] => 0
[keyspace_hits] => 352596
[keyspace_misses] => 0
[pubsub_channels] => 0
[pubsub_patterns] => 0
[latest_fork_usec] => 0
[migrate_cached_sockets] => 0
[role] => master
[connected_slaves] => 0
[master_repl_offset] => 0
[repl_backlog_active] => 0
[repl_backlog_size] => 1048576
[repl_backlog_first_byte_offset] => 0
[repl_backlog_histlen] => 0
[used_cpu_sys] => 19.33
[used_cpu_user] => 6.46
[used_cpu_sys_children] => 0.00
[used_cpu_user_children] => 0.00
[cluster_enabled] => 0
[db0] => keys=352653,expires=0,avg_ttl=0
)

 

Про APC нужно почитать, я так понял это расширение пхп. А мемкеш и так задействован.

 

Да, в мемкеше данные те, что в БД, чтоб не нагружать редис. Точнее небольшая часть, чтоб не лезть лишний раз с гет запросом. Просто раньше была mysql, я переписал под редис и решил мемкеш оставить.

 

Все оказалось просто, считал количество по маске при каждом добавлении командой keys, которая жрет эти 0.07 секунды. Сделал счетчик через ключ - скрипт взлетел за 5 секунд.
Также убрал memcache. Он медленнее работает)