Comments 12
Особо горячий кеш можно бы прямо в shared_dict самого nginx хранить, чтобы и в redis не ходить, не мучать его.
+5
У нас значения в redis обновляются каждые 1-5 минут с помощью php. Поэтому данные нужно забирать именно от туда. Но про shared_dict хорошее замечание, посмотрю, можно ли его будет где применить.
0
Так можно же не вечно хранить в локальной памяти: поставьте ttl (в терминах модуля это параметр exptime) записям на секунды-минуты. Тут уж зависит от вашей бизнес логики)
Один Redis не вытянет нагрузку, которую сможет принять и переварить nginx_lua с локальным shared_dict в качестве «сверх-горячего» кеша.
Один Redis не вытянет нагрузку, которую сможет принять и переварить nginx_lua с локальным shared_dict в качестве «сверх-горячего» кеша.
+1
цифры ab — ниочём. т.е. 100 запросов не говорят абсолютно ни-че-го. общее время почти 4 сек похоже на первичный прогрев самого php (не знаю, что там именно в нём бывает на старте, но это магия какая-то) или коннект к редису из php… в любом случае выглядит, как нереальная чушь. ну сами посудите — это нормально, что php-скрипт, делающий выборку одного значения из redis, отрабатывает МИНИМУМ за 2.2 секунды? 75% были дольше 3х секунд.
100 запросов на concurrency 100 это значит, что прилетает разом пачка в 100 запросов и они дружно «инитятся». сделайте 10к запросов хотя бы и тогда уже смотрите на числа.
100 запросов на concurrency 100 это значит, что прилетает разом пачка в 100 запросов и они дружно «инитятся». сделайте 10к запросов хотя бы и тогда уже смотрите на числа.
+5
Соглашусь, экономия на спичках. Такие вещи не всплывут в гите. Все же авторизация — часть приложения.
0
Они точно дружно инитятся или становятся в очередь php-fpm?
0
Я не знаю, что происходит со стороны nginx+php (с первым довольно посредственный опыт, второй вообще мимо меня), но ab делает 100 потоков и инитит 100 http-запросов. Как их там обрабатывает уже принимающая сторона — зависит от многого. Сразу все параллельно инитятся или в очередь встают (скорее второе, потому что уже начинает играть кол-во воркеров nginx)… Я больше про то, что -c 100 -n 100 — неимоверно бессмысленная конструкция.
0
Количество воркеров nginx не связано с количеством параллельно обрабабываемых соединений
0
ага, ваще никак
Syntax: worker_connections number;
Sets the maximum number of simultaneous connections that can be opened by a worker process.
Syntax: worker_connections number;
Sets the maximum number of simultaneous connections that can be opened by a worker process.
0
Небольшой оффтоп, но близкий по теме.
У меня есть задача — построить отказоустойчивый comet сервер(longpolling\websockets). Сейчас использую nginx-push-stream модуль, все хорошо работает, только если нода падает и клиент переключается на другую — сообщения теряются. Как один из вариантов решений, казалось бы безумным — а не построить ли это на HaProxy+Nginx+Lua+Redis. Еще опыта с nginx+lua нет, интересно насколько реалистично такое реализовать или есть другие решения?
Особенность в том, что у каждого клиента свой канал и если клиент отключился на время, то сообщение все-равно должно сохраняться в очередь с некоторым TTL, вдруг клиент переподключится(разрыв связи) — и получит все сообщения.
У меня есть задача — построить отказоустойчивый comet сервер(longpolling\websockets). Сейчас использую nginx-push-stream модуль, все хорошо работает, только если нода падает и клиент переключается на другую — сообщения теряются. Как один из вариантов решений, казалось бы безумным — а не построить ли это на HaProxy+Nginx+Lua+Redis. Еще опыта с nginx+lua нет, интересно насколько реалистично такое реализовать или есть другие решения?
Особенность в том, что у каждого клиента свой канал и если клиент отключился на время, то сообщение все-равно должно сохраняться в очередь с некоторым TTL, вдруг клиент переподключится(разрыв связи) — и получит все сообщения.
0
Sign up to leave a comment.
Nginx + Lua + Redis. Эффективно обрабатываем сессию и отдаем данные