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