Факторы, влияющие производительности Redis

Есть несколько факторов, имеющих прямые последствия для производительности Redis. Отметим их здесь, так как они могут изменить результат каких-либо ориентиров. Пожалуйста, обратите внимание, однако, что типичный экземпляр Redis работает на нижнем конце, ненастроенной окно, как правило, обеспечивает достаточную хорошую производительность для большинства приложений.

• Пропускная способность сети и задержка обычно имеют прямое влияние на производительность. Это хорошая практика, чтобы использовать программу пинг, чтобы быстро проверить задержка между клиентскими и серверными хозяев нормально перед запуском отсчета. Что касается пропускной способности, как правило, полезно оценить пропускную способность в Гбит / с, и сравнить его с теоретической пропускной способностью сети. Например эталоном установка 4 KB строки в Redis в 100000 кв / сек, будет на самом деле потребляют 3,2 Гбит / с пропускной способности и, вероятно, вписывается в 10 Гбит / с линии связи, но не 1 Гбит / с одним. Во многих сценариях реального мира, Redis пропускная способность ограничена сети задолго до ограничиваясь процессора. Чтобы закрепить несколько экземпляров высокой пропускной Redis на одном сервере, то стоит задуматься положить 10 Гбит / с сетевой адаптер или несколько 1 Гбит / с сетевые адаптеры с TCP / IP соединения.
• Процессор еще один очень важный фактор. Будучи однопоточных, Redis способствует быстрый процессор с большим кэшей и не многих ядер. В этой игре, процессоры Intel в настоящее время являются победителями. Это не редкость, чтобы получить только половину производительности на процессоре AMD Opteron по сравнению с аналогичными процессорами Nehalem EP / Westmere EP / Sandy Bridge Intel с Redis. Когда клиент и сервер работают на том же поле, процессор является ограничивающим фактором с Redis-бенчмарка.
• Скорость памяти и пропускной способности памяти, кажется, менее важно для глобальной производительности, особенно для небольших объектов. Для крупных объектов (> 10 Кб), это может стать заметным, хотя. Как правило, это не очень рентабельно покупать дорогие модули памяти быстро оптимизировать Redis.
• Redis работает медленнее на виртуальной машине по сравнению с работой без виртуализации с использованием того же аппаратного обеспечения. Если у вас есть шанс, чтобы запустить Redis на физической машине это предпочтительный. Однако это не означает, что Redis медленно в виртуализованных средах, поставленные спектакли по-прежнему очень хорошо, и большинство из серьезных проблем производительности вы можете понести в виртуализированных средах, в связи с более-резервирования, без локальных дисках с высокой латентностью, или старый гипервизор программное обеспечение, которое у вас медленный вилки реализации системного вызова.
• Когда программы тестов серверные и клиентские работать на том же поле, как / IP TCP замыкания и сокеты UNIX могут быть использованы. В зависимости от платформы, сокеты UNIX может достичь около 50% увеличить пропускную способность, чем TCP / IP шлейфа (на Linux, например). Поведение по умолчанию Redis-бенчмарка является использование TCP / IP шлейф.
• Бенефис сокетов Unix по сравнению с TCP / IP шлейфа имеет тенденцию к снижению, когда конвейерная активно используется (т.е. длинные трубопроводы).
• При наличии сетевого используется для доступа к Redis, агрегирования команды с помощью конвейерной особенно эффективно, когда размер данных хранится под размер пакетов Ethernet (около 1500 байт). На самом деле, обработка 10 байт, 100 байт, или 1000 байтов запросов почти привести в то же пропускной способности.
• На нескольких процессорных разъемов серверов, производительность Redis становится зависимой от конфигурации NUMA и место процесса. Наиболее заметным эффект, что результаты тестов Redis-кажется недетерминированным потому клиентские и серверные процессы распределены случайным образом на основных. Чтобы получить детерминированных результатов, необходимо использовать инструменты размещения процесс (на Linux: набор задач или numactl). Наиболее эффективным сочетание всегда ставить клиента и сервера на двух разных ядер том же процессоре, чтобы извлечь выгоду из кэша L3.
• С высокого класса конфигурации, можно достичь более высокой пропускной способности путем настройки NIC (ы) конфигурации и связанные перерывов. Лучший пропускная способность достигается установкой сродство между Rx / Tx очередей NIC и процессорных ядер, и активации RPS (прием пакетов Руководящий) поддержку. Более подробная информация в этом потоке. Jumbo кадры могут также обеспечить повышение производительности при больших объектов используются.
• В зависимости от платформы, Redis может быть скомпилирован с разных распределителей памяти (Libc таНос, jemalloc, tcmalloc), которые могут иметь различное поведение в перспективе сырой скорости, внутренней и внешней фрагментации. Если вы не собрали Redis самостоятельно, вы можете использовать команду INFO, чтобы проверить поле mem_allocator. Пожалуйста, обратите внимание большинство тестов не работать достаточно долго, чтобы генерировать значительные внешней фрагментации (вопреки случаях производство Redis).