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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru