Во-первых, вы можете прочитать the Redis benchmark page. Это дает хорошее резюме основных моментов для проверки настройки Redis.
Даже если вы не используете конвейерную обработку, 300 GET в 150 мс не так эффективны. Это означает, что средняя задержка составляет 500 us. Однако это зависит от размера ваших объектов. Большие объекты, больше латентности. На моем очень старом 2 ГГц ядре AMD я могу измерить 150 наших задержек для небольших объектов (несколько байтов).
Чтобы быстро проверить среднюю задержку экземпляра Redis, вы можете использовать:
$ redis-cli --latency
Обязательно используйте недавно Redis версию (не 2.4), чтобы получить эту возможность. Примечание: 2.4 сейчас довольно старый, используйте Redis 2.6 - скомпилируйте свою версию Redis, если это необходимо, это очень просто.
Чтобы быстро запустить тест для изучения задержки, вы можете запустить:
$ redis-benchmark -q -n 10000 -c 1 -d average_size_of_your_objects_in_bytes
Он работает с уникальным соединением и не конвейерным, так что задержка может быть выведена из пропускной способности. Попробуйте сравнить результаты этих тестов с цифрами, измеренными с вашим приложением.
Есть несколько пунктов, которые Вы можете проверить:
- Какая клиентская библиотека Redis вы используете? С каким языком разработки? Для некоторых языков сценариев вам необходимо установить модуль hiredis для получения эффективного клиента.
- Является ли ваша машина виртуальной машиной? На какой ОС?
- Являются ли связи с Redis постоянными? (т. е. вы не должны подключаться/отключаться при каждом HTTP-запросе вашего сервера приложений).
Почему это лучше с memcached? Ну, один экземпляр memcached, безусловно, более масштабируемый и может быть более отзывчивым, чем один экземпляр Redis, поскольку он может работать на нескольких потоках. Redis работает быстро, но однопоточно - выполнение всех команд сериализуется. Поэтому, когда команда идет на соединение, все остальные клиенты должны ждать - плохая латентность по заданной команде будет также влиять на все ожидающие команды. Как правило, при низкой пропускной способности производительность сопоставима.
При 1000 q/s (низкая пропускная способность по стандартам Redis или memcached), я бы сказал, что более вероятно, что ваша проблема на стороне клиента (т.выбор клиентской библиотеки, подключение/отключение и т. д.), чем с самим сервером Redis.
Наконец, я должен упомянуть, что если вы создаете несколько запросов Redis для HTTP-запроса, рассмотрите pipelining команды, которые вы отправляете Redis, насколько это возможно. Это действительно ключевой момент для разработки эффективных приложений Redis.
Если ваши серверы приложений находятся в том же поле, что и Redis, вы также можете использовать сокеты домена unix вместо петли TCP для подключения к Redis. Это немного улучшает производительность (до 50% больше пропускной способности, когда конвейеризация НЕ используется).
Redis работает на том же сервере, что и что? Клиент или тот, который был запущен memcached? 150 мс для запроса Redis звучит так, будто вы нажимаете swap/disk, а не память, или вы имеете в виду 150 мс для всех 300 запросов? –
Это веб-приложение со 100 запросами apache в секунду. Redis работает на том же хосте, что и сам веб-приложение, и сервер базы данных mysql, но мы планируем скоро переместить apache на 3-х распределенных серверов. Текущий сервер имеет около 64 ГБ оперативной памяти, redis занимает около 100 МБ. Существует достаточно свободного бара и нет проблем с процессором или io. Сервер не переключается на диск. И да, я имею в виду 150 мс для 300 запросов, но memcached занимал только 40 мс при тех же условиях. – ak2
Единственное, что я могу придумать, - это использовать общее подключение к Redis для всех запросов вместо одного для каждого веб-запроса, у вас могут быть проблемы с задержкой с Redis, но при 1000 запросах в секунду вы не должны видеть эту плохую задержку. Извините, ничего не очень полезно с моего направления сегодня :) –