proxy cache stampede

[Maxim Dounin]

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