Re: proxy cache stampede

[Gena Makhomed <gmm@xxxxxxxxx>]

On 22.09.2011 22:50, Daniel Podolsky wrote:

> > > То, что nginx открывает больше одно коннекта к бекенду для контента,
> > > который все равно собирается закешировать - это плохо и неправильно.
> > Слова "греховно", "плохо", "неправильно" и т.п. обычно применяются
> > манипуляторами, когда они хотят добиться желаемого результата,
> > "надавив" таким образом на чувство вины и т.п. "кнопки".
> Это в техническом смысле плохо и неправильно.
> У кого хотите спросите, да хоть бы и у самого Игоря Сысоева :)
А вот если в техническом плане - то есть просто более или менее
оптимальные алгоритмы и их реализации в коде. Без лишних эмоций.

> > > Другое дело, что реализовывать busy locks в лоб через убогий ipc - это
> > > еще хуже и неправильней.
> > Пожалуйста, присылайте патч с хорошим и правильным решением проблемы.
> А его нет, правильного решения проблемы.
не понимаю, тогда о чем мы тут вообще и с какой целью сейчас говорим?
и что Вы называете словом "правильное решение проблемы" в таком случае?

> Есть очень плохое решение - сделать на shmem, и плохое - сделать в
> рамках одного воркера.
разрешите спросить, почему же решение через shared mem плохое ?
например, таким способом в nginx работает limit_req / limit_conn

и если это "очень плохое решение", то Вы наверно можете
предложить какое-то более оптимальное решение этой проблемы?

"сделать в рамках одного воркера" - это вообще не решение.
(в смысле - это не solution и не workaround, толку будет 0)

> Так что я как раз очень понимаю, почему в nginx -
> и в большинстве кеширующих прокси - этого функционала нет.
потому что это очень мало кому (кроме CDN) надо в действительности.
статику - лучше раздавать напрямую с диска, а не качать с backend`а.

и реализация этой функциональности (необходимой только CDN) в nginx
спровоцирует очередную волну демпинга и обвал рынка услуг CDN, имхо.

особенно, если сделать это в nginx "правильно" и наиболее оптимально -
с поддержкой Range-запросов, когда в первую очередь будут скачиваться
с backend`а те фрагменты файла, которые запрашивал клиент, и если в кеше
не окажется каких-то фрагментов при новом запросе - то тянуть только их,
и хранить кеш файла в sparse file, докачивая отсутствующие части
по мере необходимости, при этом сразу отдавая клиентам те части,
которые уже скачаны, не дожидаясь пока полностью весь файл
будет получен с backend`а и записан в кеш.

у кого есть свободное время, желание и возможность
реализовать такой алгоритм в виде патча к nginx?..
вот и я о том же: 3-в-1 пока что нет ни у кого.

хотя, кроме демпинга и обвала рынка услуг CDN, это спровоцирует также
и ускорение роста показателей "increase in market share" на странице

http://news.netcraft.com/archives/2011/09/06/september-2011-web-server-survey.html
September 2011 Web Server Survey

хотя, и сейчас уже nginx занимает первое место
в мире по темпам роста показателя "market share":

Nginx had the biggest increase in market share,
with a growth of 0.36 percentage points.

но с другой стороны, - чем больше будет "market share"
у nginx, - тем больше появится пользователей, которые начнут
требовать "сделайте мне красиво", обвиняя при этом в греховности.

--
Best regards,
 Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru