Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proxy cache stampede
Hello!
On Fri, Sep 23, 2011 at 03:04:27AM +0400, Daniel Podolsky wrote:
> > не понимаю, тогда о чем мы тут вообще и с какой целью сейчас говорим?
> > и что Вы называете словом "правильное решение проблемы" в таком случае?
> Не нервничайте так :) Вы и не обязаны меня понимать...
>
> > разрешите спросить, почему же решение через shared mem плохое ?
> > например, таким способом в nginx работает limit_req / limit_conn
> Одно дело - пяток переменных для пятка локешенов, определенных
> администратором, и другое - флаг для каждого
> проксируемого-в-настоящий-момент-и-кешабельного-URL.
> А ведь в shmem даже банальный hash не запихнешь.
Rbtree запихнёшь, а hash и не нужен - hash в nginx'е это
неповоротливая структура, создающаяся очень не быстро (но
оптимально) и предназначенная для быстрого доступа к данным,
известным на этапе чтения конфига.
Собственно, limit_req/limit_conn именно на rbtree и работают. И
там не "пяток переменных", там ограничения по произвольному ключу.
С shmem совсем другая проблема: нет нормального способа быстро и с
малыми затратами сообщать в соседние воркеры о новых событиях
(i.e. "файл такой-то появился наконец в кеше, забирайте кому
надо").
[...]
> > "сделать в рамках одного воркера" - это вообще не решение.
> > (в смысле - это не solution и не workaround, толку будет 0)
> мне бы сгодилось
Видимо, именно так оно и будет на начальном этапе. Для случая
одного рабочего процесса это полностью решает проблему, для N
рабочих процессов - ограничивает числом N соответственно.
Maxim Dounin
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
