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

[Trurl McByte]

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

> proxy_max_temp_file_size вообще не имеет к размеру файлов в кеше никакого
> значения
> Цитата:
> Директива задаёт максимальный размер временного файла для проксированного
> ответа. "proxy_max_temp_file_size 0" запрещает создание файла.
>
> Т.е. определяет может ли nginx писать ответ бекенда на диск перед отдачей
> клиенту, или ему придется отдавать его на лету.
>

В том то и дело что это только в теории и по логике вещей. А на практике,
при включенном кешировании, nginx плюет на proxy_max_temp_file_size и
пишет, сколько ему нужно.

вот например процесс выкачки 67M файлика
в середине процесса:
-rw------- 1 nginx nginx 43778048 Jan 28 13:32 7/7/0000000077
...
в конце:
-rw------- 1 nginx nginx 69885952 Jan 28 13:34 7/7/0000000077
сколько там стоит proxy_max_temp_file_size - по барабану, хоть 0, хоть 8M.



> При этом общий объем отдачи клиенту и этот размер никак не коррелируют.
> Ответ может быть 10Тер, а размер временного файла 1Мег, тогда nginx может
> каждый пришедший 1Мег записывать на диск и потом отдавать клиенту, и все
> это
> в цикле, (пока все не посинеют)))
> Хотя никто не сказал, что будет если размер ответа известен сразу и
> превышает  - nginx может отказаться писать ответ во временный файл, если
> сочтет это не эффективным.
> Полезность его установки в больше нуля только в одном - если надо
> разгрузить
> бекенды для новых запросов при неторопливых клиентах (или такого вида
> атаки)
> Но если у вас система обрабатывает 100к запросов, и вы поставили размер в
> 1мег, то это может потребовать 100Гиг диска для временного хранения
> ответов.
> И нехилый вобщем disk-io )))
>


До 100 гиг не доходило, но до 50 гиг уже не раз.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130128/b24fe181/attachment-0001.html>