Re: помогите понять логику кеширования и буферизации

[Trurl McByte]

29 января 2013 г., 23:18 пользователь teo <nginx-forum at nginx.us> написал:

> Я выкинул не непонятное, а то, что не имело отношение к делу.
> Еще раз перечитал - интересно каким образом можно восстановить какую именно
> директорию вы там сканируете если пути относительные?
>

по длине имени самого файла. В temp они короче.


> Пути во временной директории - ровно такие же, как и в том месте, куда они
> потом должны попасть - ну может быть сгенерены для другого ключа, хотя
> врядли.
> Если файл пишется во временную директорию, указанную при описании кеша -
> значит решение о помещении его в кеш уже принято, и не важно в данном
> случае
>
- временная это директория или уже реальная. Хотя да, различие есть т.к.
> "расти" файл может только во временной директории - так что вы приводили
> сканирование именно временной директории. Только сути это не меняет.
>

я всего лишь пытался показать, что параметр proxy_max_temp_file_size
никакой роли не играет. Даже в кеш этот файл попасть не должен был, потому
как  max_size=5m. Но этот параметр тоже работает только задним числом и то
не всегда. При скачивании очень больших файлов оные остаются в кеше очень
на долго (не взирая на все ограничения), поскольку пока первый запросивший
его стянет по своим медленным каналам - к тому времени появится еще один
желающий стянуть тот же файл. В результате размер temp+кеша гарантировано
больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и  до
переполнения диска. То есть использование nginx на продакшене на сайтах с
геобалансингом и большим количеством крупного контента сопряжено с
серьезными рисками.


> Я честно пытался 2ды объяснить - видимо не судьба. Остается уже спросить -
> а
> если вообще при описании локейшена не будет задано никаких кешей?
> То имеет ли смысл указание этого параметра или без кеша оно не имеет
> смысла?
>

Если бы он работал как вы описали - то да, имело бы смысл.


> Можете ответить на этот вопрос сами себе - мне это уже не интересно.
> По-моему пора прекратить препирательства - я рад что вы нашли способ как
> побороть nginx в вашем случае.
>

Нормальный софт не надо бороть.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130130/7f04c4a8/attachment.html>