Comments 43
Что-то не пойму. Первый тест с UNIX сокетом у вас отработал за 8.6 секунд против 6-три для TCP, но вы пишите что TCP на 30% медленнее. В чем ошибка: в тестах или резолюции? Или я что-то не понимаю?
Сам использую TCP. Так надежней.
Не понятно, тюнинговали ли вы ОС для того, что бы работать с таким количеством соединений (касаемо и сокетов и TCP).
За 3 секунды Redis не успел их у себя до конца обработатьа 3 секунды это проблема редиса или то что php не успел?
Да лимиты убраны. 3 секунды это скорее проблема редиса. То есть форки отдали на сервер редиса incr, потом завершили работу, потом родительский процесс об этом узнал (что все закончили работу), после чего делает еще одно соединение с редисом и запрашивает количество.
Как итог — нужно время чтобы оно успело обработаться.
Тут скорее дело в том, что тот же MySQL блокирует записи на чтение при UPDATE, редис же так не делает, поэтому нужно учитывать, что после завершения работы в фоне множества процессов, сразу получить самые свежие данные не получится.
Как итог — нужно время чтобы оно успело обработаться.
Тут скорее дело в том, что тот же MySQL блокирует записи на чтение при UPDATE, редис же так не делает, поэтому нужно учитывать, что после завершения работы в фоне множества процессов, сразу получить самые свежие данные не получится.
А не могли бы выложить тестовый скрипт интересно сравнить у себя. И какая версия PHP использовалась?
Покажите вывод
Количество одновременно открытых UNIX-сокетов ограничено максимальным количеством файловых дескрипторов. Там у вас и сидит значение меньше миллиона. Его вы не изменили для теста, поэтому и ошибки полезли.
cat /proc/sys/fs/file-maxКоличество одновременно открытых UNIX-сокетов ограничено максимальным количеством файловых дескрипторов. Там у вас и сидит значение меньше миллиона. Его вы не изменили для теста, поэтому и ошибки полезли.
Да вы правы — стоит 100 тысяч. Вот кстати еще важная деталь.
Не совсем правы. Поставил миллион. Попробовал — все равно ошибки.
Потом вспомнил — тут 1000 процессов делают по 1000 соединений в цикле. Одновременно может быть не более 1000 соединений. (Каждый процесс делает одновременно лишь один коннект а потом дисконнект)
При этом лимит 100 тысяч.
Так что лимит тут не виноват, а что то другое.
Потом вспомнил — тут 1000 процессов делают по 1000 соединений в цикле. Одновременно может быть не более 1000 соединений. (Каждый процесс делает одновременно лишь один коннект а потом дисконнект)
При этом лимит 100 тысяч.
Так что лимит тут не виноват, а что то другое.
Не совсем правы Вы :)
Попробуйте так задать:
`
ulimit -Sn 101000
sysctl -w fs.file-max=1001000
`
- Одновременно соединений у вас больше, потому что после
closeне поставлены скобки. Функция без скобок в PHP не вызывается. - Лимит надо ставить не на миллион, а больше, потому что есть еще другие системные процессы плюс сам редис под себя часть дескриптором забирает. Почитайте тут: http://redis.io/topics/clients
Попробуйте так задать:
`
ulimit -Sn 101000
sysctl -w fs.file-max=1001000
`
Ну и еще maxclients для Redis надо увеличить за миллион :)
Увеличил лимиты еще, поставил max_clients (кстати с tcp и так работало )
Насчет close — даже если его не писать — все равно при завершении дочернего процесса же срабатывает деструктор. Т.е. соединение закрывается.
Итог таков что даже увеличив лимиты и т.д. — все равно UNIX сокет не работает при таком количестве запросов, а tcp работает.
Насчет close — даже если его не писать — все равно при завершении дочернего процесса же срабатывает деструктор. Т.е. соединение закрывается.
Итог таков что даже увеличив лимиты и т.д. — все равно UNIX сокет не работает при таком количестве запросов, а tcp работает.
Редис работает в однопоточном режиме, хотя бы по этому не стоит слать в него 1000+ одновременных запросов. И возможно именно с этим и связана ошибка "Redis server went away in".
Извиняюсь, а какая ОС участвовала в тесте? По моим наблюдениям, на убунте сокеты работают быстрее, чем на центОС. А на генту — быстрее убунты в разы (но генту-парк серверов сложнее поддерживать)
Исправьте выводы в посте, пожалуйста. Вам уже подсказали выше в комментариях о причинах ваших не правильных выводов.
Unix-сокет быстрее и надежнее TCP-сокета. Единственным недостатком использования Unix-сокета является является более сложная экосистемы.
Кстати, использовать PHP как промежуточный слой для тестирования именно редиса — не самое удачное решение.
Unix-сокет быстрее и надежнее TCP-сокета. Единственным недостатком использования Unix-сокета является является более сложная экосистемы.
Кстати, использовать PHP как промежуточный слой для тестирования именно редиса — не самое удачное решение.
Мы так до конца и не разобрались. У вас бенчмарк на UNIX сокетах нормально работает на 1000 форках?
Вот этот комментарий: https://habrahabr.ru/company/pushall/blog/280218/#comment_8823146 исчерпывающе объясняет почему у вас появились проблемы.
От себя могу добавить, что у меня Редис работает c 2011-го через Unix-сокет ни разу не было проблем. Хатя нагрузки были вполне приличные.
Да и с точки зрения ОС Unix-сокет не может быть менее надежным. Я поэтому удивился когда увидел у вас такие выводы. TCP-сокет добавляет сетевой стек — это его принципиальное отличие.
У меня не установлен php 7, поэтому, к сожалению, ваш бенчмарк запустить не могу.
От себя могу добавить, что у меня Редис работает c 2011-го через Unix-сокет ни разу не было проблем. Хатя нагрузки были вполне приличные.
Да и с точки зрения ОС Unix-сокет не может быть менее надежным. Я поэтому удивился когда увидел у вас такие выводы. TCP-сокет добавляет сетевой стек — это его принципиальное отличие.
У меня не установлен php 7, поэтому, к сожалению, ваш бенчмарк запустить не могу.
Этот код работает начиная с php 5.5 где то.
Насчет комментария — описал же, что не помогло это.
Причем с pconnect все работает.
Насчет нагрузок — сомневаюсь что вы писали в редис одновременно в 1000 потоков. Тут вероятно, что сам redis не справляется через UNIX сокет т.к. слишком быстро идут запросы, а TCP из за доп оверхеда соединения уменьшает нагрузку на сам redis.
Чтобы писать в 1000 потоков одновременно (сами смотрите, это было миллион за 4 секунды) вам нужно делать 250 тысяч запросов в секунду. При этом бенчмарк редиса (redis-benchmark) у меня лично показывает где то 100 тысяч запросов в секунду.
То есть — чтобы достичь тех же нагрузок — вам нужно редис на 100 загрузить.
У меня на тестах редис показывал 100% потребления одного ядра. То есть по сути эти был его предел по обработке.
Но все таки тот факт, что TCP в случае нагрузки замедляется, а в UNIX socket просто отваливается — мне кажется первый вариант лучше.
Насчет комментария — описал же, что не помогло это.
Причем с pconnect все работает.
Насчет нагрузок — сомневаюсь что вы писали в редис одновременно в 1000 потоков. Тут вероятно, что сам redis не справляется через UNIX сокет т.к. слишком быстро идут запросы, а TCP из за доп оверхеда соединения уменьшает нагрузку на сам redis.
Чтобы писать в 1000 потоков одновременно (сами смотрите, это было миллион за 4 секунды) вам нужно делать 250 тысяч запросов в секунду. При этом бенчмарк редиса (redis-benchmark) у меня лично показывает где то 100 тысяч запросов в секунду.
То есть — чтобы достичь тех же нагрузок — вам нужно редис на 100 загрузить.
У меня на тестах редис показывал 100% потребления одного ядра. То есть по сути эти был его предел по обработке.
Но все таки тот факт, что TCP в случае нагрузки замедляется, а в UNIX socket просто отваливается — мне кажется первый вариант лучше.
За 3 секунды Redis не успел их у себя до конца обработать — это одна из деталей, которую надо учитывать. Если слишком быстро считывать значения, можно поймать момент, когда они еще старые.
Редис же однопоточный и, как следствие, все операции выполняет атомарно. Или я отстал от жизни и редис сейчас уже многопоточный?
Да тоже странно. Может действительно не до конца соединения закрываются. Либо он обрабатывает уже после того как отпускает клиент.
Честно скажу, исходники Редиса не ковырял, но как я себе представляю его устройство: он может держать открытыми несколько соединений, но обрабатывает их он один за одним. Полностью. Могу ошибаться, конечно, но как иначе в рамках однопоточной архитектуры?
Может быть проблема в php-клиенте или вашем коде?
Может быть проблема в php-клиенте или вашем коде?
Я же говорю — сам увидился. Конечно как вариант, может php-redis вообще сразу передает управление дальше, т.е. я отправляю incr, после чего у меня идет закрытие соединения, а вот сам модуль php-redis возможно в этот момент все это отправляет.
Но вообще я сильно сомневаюсь в этом.
Но вообще я сильно сомневаюсь в этом.
Поковырял пример, это просто кривовато сделано сообщение об ошибке в pecl-redis, я прикрутил TinyRedisClient там выдается ошибка "Resource temporarily unavailable" при подключении к сокету, т.е. до Redis дело даже не доходит.
Проблема из-за того, что Redis все подключения по сокету делает неблокирующимися, и на каком-то этапе заполняется буфер, и выдается ошибка EAGAIN. Теоретически можно лечить установкой таймаута сокета SO_SNDTIMEO. Т.е. по сути это бага не Redis'а, а конкретного драйвера PHP. Что подтверждается тем, что redis-benchmark с параметром -с 1000 (т.е. одновременное подключение 1000 клиентов) нормально отрабатывает через сокеты.
Проблема из-за того, что Redis все подключения по сокету делает неблокирующимися, и на каком-то этапе заполняется буфер, и выдается ошибка EAGAIN. Теоретически можно лечить установкой таймаута сокета SO_SNDTIMEO. Т.е. по сути это бага не Redis'а, а конкретного драйвера PHP. Что подтверждается тем, что redis-benchmark с параметром -с 1000 (т.е. одновременное подключение 1000 клиентов) нормально отрабатывает через сокеты.
Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Открыл статистику на нашем сервере, воскресенье вечер: 5740 запросов в секунду.
Как мы работаем в будни вообще не представляю.
Открыл статистику на нашем сервере, воскресенье вечер: 5740 запросов в секунду.
Как мы работаем в будни вообще не представляю.
5740 запросов в секунду.
А тестах выше у нас миллион за 35 секунд. Т.е. 28 тысяч в секунду.
Теперь интересно, какое у вас железо? У нас вот 28 тысяч в секунду на одном ядре Intel Xeon E5-1650v2 3.5 Ghz обрабатывается. И еще деталь — 28 тысяч — инкрементов в секунду.
И самая важная деталь — это 28 тысяч соединений в секунду.
Я немного модифицировал бенчмарк, сделал 100 потоков по 10000 инкрементов через 100 соединений. И о чудо миллион инкрементов за 10 секунд.
100 тысяч инкрементов за 1 секунду. В 20 раз больше инкрементов, чем у вас запросов в секунду, на одном ядре. При этом нагрузка не сильно большая, все внутри оперативки работает.
MySQL при таком количестве селектов (5000) в секунду, скорее всего ест несколько ядер.
А теперь я еще модифицировал скрипт. Вот он теперь делает один SET и миллион GETов (типичные SELECT'ы для MySQL) и о чудо — за 3 секунды миллион GET'ов. Т.е. 333 тысячи селектов за секунду на одном ядре. В 60 раз быстрее.
И теперь на секундочку — сколько у вас в секунду идет UPDATE и INSERT? У нас проблема именно в том, что к нам идут несколько тысяч ответных запросов на установление статуса уведомления у определенного пользователя, можете ли вы обработать 5000 инсертов, а потом еще 5000 обновление полей? И так, чтобы не спавнить 5000 форков PHP-FPM, т.е. нужно обрабатывать запросы быстрее чем за 10-20 мс, иначе слишком много процессов скопится.
А тестах выше у нас миллион за 35 секунд. Т.е. 28 тысяч в секунду.
Теперь интересно, какое у вас железо? У нас вот 28 тысяч в секунду на одном ядре Intel Xeon E5-1650v2 3.5 Ghz обрабатывается. И еще деталь — 28 тысяч — инкрементов в секунду.
И самая важная деталь — это 28 тысяч соединений в секунду.
Я немного модифицировал бенчмарк, сделал 100 потоков по 10000 инкрементов через 100 соединений. И о чудо миллион инкрементов за 10 секунд.
100 тысяч инкрементов за 1 секунду. В 20 раз больше инкрементов, чем у вас запросов в секунду, на одном ядре. При этом нагрузка не сильно большая, все внутри оперативки работает.
MySQL при таком количестве селектов (5000) в секунду, скорее всего ест несколько ядер.
А теперь я еще модифицировал скрипт. Вот он теперь делает один SET и миллион GETов (типичные SELECT'ы для MySQL) и о чудо — за 3 секунды миллион GET'ов. Т.е. 333 тысячи селектов за секунду на одном ядре. В 60 раз быстрее.
И теперь на секундочку — сколько у вас в секунду идет UPDATE и INSERT? У нас проблема именно в том, что к нам идут несколько тысяч ответных запросов на установление статуса уведомления у определенного пользователя, можете ли вы обработать 5000 инсертов, а потом еще 5000 обновление полей? И так, чтобы не спавнить 5000 форков PHP-FPM, т.е. нужно обрабатывать запросы быстрее чем за 10-20 мс, иначе слишком много процессов скопится.
Ну так вы определитесь. Несколько тысяч запросов в секунду или десятки тысяч.
Синтетика типа инкременты в секунду ни о чем не говорит.
У нас сложная бизнес логика. Почти всё селекты, да.
У вас же не основана вся логика на одном инкременте?
Чтобы не спавнить 5000 форков PHP-FPM, я бы вообще не стал делать это на php, он для такого крайне не подходит.
Так что все очень относительно.
Какой размер данных, что вы пишите/обновляете.
Все это влияет на то как быстро отработает и сколько вытянет.
И конечно разница существенная с оперативкой работать или с файлами.
Синтетика типа инкременты в секунду ни о чем не говорит.
У нас сложная бизнес логика. Почти всё селекты, да.
У вас же не основана вся логика на одном инкременте?
Чтобы не спавнить 5000 форков PHP-FPM, я бы вообще не стал делать это на php, он для такого крайне не подходит.
Так что все очень относительно.
Какой размер данных, что вы пишите/обновляете.
Все это влияет на то как быстро отработает и сколько вытянет.
И конечно разница существенная с оперативкой работать или с файлами.
Фраза
"Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать."
Как раз имела в виду, что делать такое число UPDATE'ов в MySQL очень тяжело.
"У нас сложная бизнес логика. Почти всё селекты, да." Вот тут и выходит. Селекты делать не проблема. Хотя проблема начинается, когда идет 1000 UPDATE'ов и селекты одновременно связанные с обновляемыми строками — а они все лочатся.
Собственно поэтому мы будем частично использовать Redis + еще использовать его как буфер. Т.е. набрали за пару секунд данных, а потом уже сбросили это в БД одиночным запросом.
Насчет тысяч и десятков тысяч — скорее всего у вас на эти 5000 запросов, всего 100-200 UPDATE/INSERT в секунду. Так что да — нам нужно те же 5000 — только UPDATE запросов.
"Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать."
Как раз имела в виду, что делать такое число UPDATE'ов в MySQL очень тяжело.
"У нас сложная бизнес логика. Почти всё селекты, да." Вот тут и выходит. Селекты делать не проблема. Хотя проблема начинается, когда идет 1000 UPDATE'ов и селекты одновременно связанные с обновляемыми строками — а они все лочатся.
Собственно поэтому мы будем частично использовать Redis + еще использовать его как буфер. Т.е. набрали за пару секунд данных, а потом уже сбросили это в БД одиночным запросом.
Насчет тысяч и десятков тысяч — скорее всего у вас на эти 5000 запросов, всего 100-200 UPDATE/INSERT в секунду. Так что да — нам нужно те же 5000 — только UPDATE запросов.
Если у вас 1000 форков, и каждый инициирует по 1000 соединений, легко представить ситуацию, когда открыто более 100 соединений. Полагаю, что в этом случае стоит увеличить значение net.core.somaxconn до значения большего, чем пиковое количество одновременных соединений.
В свою очередь, для TCP соединений, вы используете ту же машину, которая на каждое соединение "расходует исходящий порт", соотвественно, возможна ситуация, когда вы израсходуете весь local_range. Стоит посмотреть диапазон указанный в net.ipv4.ip_local_port_range и увеличить его.
Также, полагаю, что за время теста в dmesg насыпало более понятных логов о причинах проблем.
/proc/sys/net/core/somaxconn: Limit of socket listen() backlog, known in userspace as SOMAXCONN. Defaults to 128. The value should be raised substantially to support bursts of request. For example, to support a burst of 1024 requests, set somaxconn to 1024.В свою очередь, для TCP соединений, вы используете ту же машину, которая на каждое соединение "расходует исходящий порт", соотвественно, возможна ситуация, когда вы израсходуете весь local_range. Стоит посмотреть диапазон указанный в net.ipv4.ip_local_port_range и увеличить его.
Также, полагаю, что за время теста в dmesg насыпало более понятных логов о причинах проблем.
Смотрели в сторону aerospike?
И очень интересно было бы увидеть этот же бенчмарк на другом языке.
И очень интересно было бы увидеть этот же бенчмарк на другом языке.
Лично я с такими вещами, как Redis, MySQL и т.п. использую всегда TCP, а вот с php-fpm, uwsgi и gunicorn всегда использую UNIX-сокет.
Просто чтобы внести некоторую ясность.
Я описывал тут кейс, как со своими кривыми руками я добился 12 тыщ в секунду на одном сервере, insert/update, на InnoDb под мускулом (Percona 5.6), естественно это все через веб входило, nginx принимал данные в виде json запросов.
Сами перконовцы до 16 тыщ разгоняют на одном сервере.
Понятно что миллион в секунду не сделать, и тут нужны другие решения. Но просто для проформы упоминаю что 5 тысяч это не меганагрузка.
Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Я описывал тут кейс, как со своими кривыми руками я добился 12 тыщ в секунду на одном сервере, insert/update, на InnoDb под мускулом (Percona 5.6), естественно это все через веб входило, nginx принимал данные в виде json запросов.
Сами перконовцы до 16 тыщ разгоняют на одном сервере.
Понятно что миллион в секунду не сделать, и тут нужны другие решения. Но просто для проформы упоминаю что 5 тысяч это не меганагрузка.
TCP (т.к. он стабильнее, или нет?
С чего вдруг?
Сокеты одного типа SOCK_STREAM. За исключением того, что в домене AF_INET мы несём накладные расходы на именование сокета, htonX'ы, муршрутизацию, asc'и принципиальных отличий от AF_UNIX нет. Как следствие, чем меньше длина пакета данных, тем больше будет выигрыш при использовании сокетов в домене файловой системы. Как правило, это порядка 50%.
Поэтому (если исключить правку кода для внедрения в редис IPS с использованием разделяемой памяти) AF_UNIX сокеты будут самыми производительными. А ввиду того, что read/write для них реализован одинаково сравнивать стабильность не приходится.
обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Ни чистых Insert'ах отправлял в продакшине данные из nginx в MySQL порядка 30'000 qps и это был не предел. На чистой синтетике (в режиме храниения данных а-ля redis — ключ/значение) думаю можно добиться и более 100'000 qps.
Тут дело не в самих сокетах, а в том как с ними работает драйвер php и сам redis.
Например также читал, что у редиса была (или еще есть?) бага, связанная с тем, что UDS не отвечает в момент записи редисом данных на диск, в то же время tcp просто ожидает ответа.
Например также читал, что у редиса была (или еще есть?) бага, связанная с тем, что UDS не отвечает в момент записи редисом данных на диск, в то же время tcp просто ожидает ответа.
Тут дело не в самих сокетах, а в том как с ними работает драйвер php и сам redis.
А что PHP или Redis используют некие несистемные средства работы с сокетами?
Листаю исходники redis. Как и ожидалось все функции anetTcp отличаются от anetUnix именно "добавлением" в Tcp-функциях getaddrinfo, bind, ntohs.
Чтение и запись реализованы в "общих" anetRead, anetWrite. И пока не могу полагать, что работа с сокетами одного типа может отличаться чем-то кроме дополнительных расходов на tcp-обработку.
Например также читал, что у редиса была (или еще есть?) бага, связанная с тем, что UDS не отвечает в момент записи редисом данных на диск, в то же время tcp просто ожидает ответа.
Ссылкой поделитесь?
"И пока не могу полагать, что работа с сокетами одного типа может отличаться чем-то кроме дополнительных расходов на tcp-обработку."
Как выше писали — проблема в буферах php-redis. Именно в нем разные реализации.
"Ссылкой поделитесь?"
https://toster.ru/q/223524
Вот еще проблема — https://github.com/phpredis/phpredis/issues/70 у многих решается как раз переходом с UDS на TCP.
Как выше писали — проблема в буферах php-redis. Именно в нем разные реализации.
"Ссылкой поделитесь?"
https://toster.ru/q/223524
Вот еще проблема — https://github.com/phpredis/phpredis/issues/70 у многих решается как раз переходом с UDS на TCP.
Sign up to leave a comment.
Redis — что быстрее, UNIX-сокет или TCP? Что стабильнее? + pconnect