Comments 12
У нас значения в redis обновляются каждые 1-5 минут с помощью php. Поэтому данные нужно забирать именно от туда. Но про shared_dict хорошее замечание, посмотрю, можно ли его будет где применить.
Так можно же не вечно хранить в локальной памяти: поставьте ttl (в терминах модуля это параметр exptime) записям на секунды-минуты. Тут уж зависит от вашей бизнес логики)
Один Redis не вытянет нагрузку, которую сможет принять и переварить nginx_lua с локальным shared_dict в качестве «сверх-горячего» кеша.
Не стоит забывать, что shared_dict хранится в памяти. В redis могут и гигабайты храниться, нехорошо будет всё это дублировать в памяти nginx. Хотя если данных немного а объём запросов огромный — почему бы и нет.
цифры ab — ниочём. т.е. 100 запросов не говорят абсолютно ни-че-го. общее время почти 4 сек похоже на первичный прогрев самого php (не знаю, что там именно в нём бывает на старте, но это магия какая-то) или коннект к редису из php… в любом случае выглядит, как нереальная чушь. ну сами посудите — это нормально, что php-скрипт, делающий выборку одного значения из redis, отрабатывает МИНИМУМ за 2.2 секунды? 75% были дольше 3х секунд.
100 запросов на concurrency 100 это значит, что прилетает разом пачка в 100 запросов и они дружно «инитятся». сделайте 10к запросов хотя бы и тогда уже смотрите на числа.
Соглашусь, экономия на спичках. Такие вещи не всплывут в гите. Все же авторизация — часть приложения.
Я не знаю, что происходит со стороны nginx+php (с первым довольно посредственный опыт, второй вообще мимо меня), но ab делает 100 потоков и инитит 100 http-запросов. Как их там обрабатывает уже принимающая сторона — зависит от многого. Сразу все параллельно инитятся или в очередь встают (скорее второе, потому что уже начинает играть кол-во воркеров nginx)… Я больше про то, что -c 100 -n 100 — неимоверно бессмысленная конструкция.
Количество воркеров nginx не связано с количеством параллельно обрабабываемых соединений
ага, ваще никак

Syntax: worker_connections number;
Sets the maximum number of simultaneous connections that can be opened by a worker process.
Ну так это общее количество запросов, включая и статику (картинки, js, CSS etc). Этому параметру можно поставить и 65000, но пхп при 65к запросов уже может загнуться.
Небольшой оффтоп, но близкий по теме.
У меня есть задача — построить отказоустойчивый comet сервер(longpolling\websockets). Сейчас использую nginx-push-stream модуль, все хорошо работает, только если нода падает и клиент переключается на другую — сообщения теряются. Как один из вариантов решений, казалось бы безумным — а не построить ли это на HaProxy+Nginx+Lua+Redis. Еще опыта с nginx+lua нет, интересно насколько реалистично такое реализовать или есть другие решения?
Особенность в том, что у каждого клиента свой канал и если клиент отключился на время, то сообщение все-равно должно сохраняться в очередь с некоторым TTL, вдруг клиент переподключится(разрыв связи) — и получит все сообщения.
Only those users with full accounts are able to leave comments. Log in, please.