Мы в PushAll обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.

Стараясь все больше операций перенести на быстрые NoSQL хранилища вроде Redis, мы хотим знать как эффективнее его использовать и не будет ли у нас проблем с большим количеством соединений.
Также для работы мы используем форки PHP и нам было интересно, а как поведет себя Redis, если мы будем делать несколько тысяч соединений в одновременно в нескольких потоках. Мы решили поделиться с сообществом нашими тестами.

Железо

Мы тестируем на одном из VPS PushAll:

CPU: Intel Xeon E5-1650v2 3.5 Ghz — 2 ядра.
RAM: 3 Gb DDR3 1866Mhz

Условия тестирования

Мы написали многопоточного бота PHP, который:

• Делает форки в цикле — 100 форков без каких либо задержек
• Каждый форк в своем цикле, 1000 раз создает соединение с Redis и производит инкремент
• Родительский процесс ждет 3 секунды и берет значение, если не ждать — Redis вернет не полное значение инкеремента

Также мы протестировали вариант с 1000 форками и как будут отличаться результаты при использовании UNIX-сокета и TCP.

100 форков, 1000 соединений в каждом, TCP

# time php benchmark.php  End:100000  real 0m6.021s user 0m0.023s sys 0m0.067s 

100 форков, 1000 соединений в каждом, UNIX-сокет

# time php benchmark.php  End:100000  real 0m8.666s user 0m0.063s sys 0m0.073s 

TCP-сокет в среднем на 30% медленнее. (напомню, тут испытывается больше не производительность работы самого Redis, а то, как он обрабатывает соединения)

1000 форков, 1000 соединений в каждом, TCP+UNIX

Повышаем ставки

TCP:

# time php benchmark.php  End:903505  real 1m7.659s user 0m0.073s sys 0m0.753s 

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

Что самое интересное, при проведение того же самого теста, но для unix-сокета, мы получаем ошибки:

Fatal error: Uncaught RedisException: Redis server went away in .... 

То есть, unix-сокет не смотря на то, что он быстрее, может обрабатывать несколько меньшее количество запросов. Либо как вариант — возможно, что из за того что он такой быстрый не справляется уже сам сервер Redis’а.

Мы проводили подобные тесты и для php-fpm — там также TCP-сокет давал меньше ошибок со связкой с NGINX чем UNIX-сокет. Разница в скорости была там незначительна.

PS. Хабр, а почему хаб MongoDB и MySQL есть, а Redis нет?

ссылка на оригинал статьи https://habrahabr.ru/post/280218/