Добрый день,

Занимаюсь оптимизацией своего проекта. Возникла следующая идея:

Скрипт формирует ответ, который в последствии через echo отдается
клиенту. Ответ может быть от нескольких сотен байт до нескольких
мегабайт.

Имеет ли смысл в случае ответа>некоего порогового X перед отдачей
сохранить его во временный файл, саму переменную ответа обнулить,
таким образом, освободив память. А далее отдать ответ примерно так:

while ( !feof( $stream ) ) echo( fread( $stream, 8192 ) );

Позволит ли это оптимизировать использование памяти?

Работаю на nginx + fast-cgi php.

Какое количество полностью отличающихся друг от друга таких ответов предвидится?

Если некоторая значительная часть всех ответов совпадает, быть может
есть смысл кешировать её в оперативке и доставать оттуда при
формировании ответов.

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

Однако если вы точно уверены, что формируемые в таком ответе данные
будут запрашиваться впоследствии не часто, то этот вариант вполне
подойдёт. Если нет, то имеет смысл оставлять их в оперативном кеше.

12 августа 2010 г. 15:59 пользователь Дмитрий <art.vprivate@gmail.com> написал:
> Добрый день,
>
> Занимаюсь оптимизацией своего проекта. Возникла следующая идея:
>
> Скрипт формирует ответ, который в последствии через echo отдается
> клиенту. Ответ может быть от нескольких сотен байт до нескольких
> мегабайт.
>
> Имеет ли смысл в случае ответа>некоего порогового X перед отдачей
> сохранить его во временный файл, саму переменную ответа обнулить,
> таким образом, освободив память. А далее отдать ответ примерно так:
>
> while ( !feof( $stream ) ) echo( fread( $stream, 8192 ) );
>
> Позволит ли это оптимизировать использование памяти?
>
> Работаю на nginx + fast-cgi php.



--
-------------------------------------------------------------
Kayo Ayanami

jabber: kayo@neko.im
gtalk-xmpp: kayo.k11.4@gmail.com
sourceforge: phoenix11@users.sf.net
luaforge: phoenix11@users.luaforge.net

За последнюю тысячу лет мы постигли печальную часть наук..
Настало время заняться чем-то другим.. (C) БГ ^_~

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

> Скрипт формирует ответ, который в последствии через echo отдается
> клиенту. Ответ может быть от нескольких сотен байт до нескольких
> мегабайт.

если ответ от несколько мегабайт - то следует оптимизировать в сторону отдачу файла средствами nginx

> Работаю на nginx + fast-cgi php.

Александр Календарев

Какие тут варианты: поместить файл в хттп папку и сделать редирект? Если так
- как при этом передать хедеры, которые мне нужно вернуть с этим ответом?

2010/8/12 Alexandre Kalendarev <akalend@mail.ru>

>
> > Скрипт формирует ответ, который в последствии через echo отдается
> > клиенту. Ответ может быть от нескольких сотен байт до нескольких
> > мегабайт.
>
> если ответ от несколько мегабайт - то следует оптимизировать в сторону
> отдачу файла средствами nginx
>
> > Работаю на nginx + fast-cgi php.
>
> Александр Календарев
>
>

On 08/12/10 18:14, Art @ Впривате wrote:
> Какие тут варианты: поместить файл в хттп папку и сделать редирект? Если
> так - как при этом передать хедеры, которые мне нужно вернуть с этим
> ответом?
>
> 2010/8/12 Alexandre Kalendarev <akalend@mail.ru <mailto:akalend@mail.ru>>
> > Скрипт формирует ответ, который в последствии через echo отдается
> > клиенту. Ответ может быть от нескольких сотен байт до нескольких
> > мегабайт.
>
> если ответ от несколько мегабайт - то следует оптимизировать в
> сторону отдачу файла средствами nginx
>
> > Работаю на nginx + fast-cgi php.
Ключевое слово - X-Accel-Redirect
Но надо сразу задуматься над тем, как чистить диск от этих файлов.

зачем чистить диск, если идет отдача постоянного контента
мне кажется изначально стоит вопрос именно в том как защитить файлы от несанкционированного доступа

хотя топикстартер от нас скрывают истинную цель
что же ему надо в конечном итоге

> Ключевое слово - X-Accel-Redirect
> Но надо сразу задуматься над тем, как чистить диск от этих файлов.

Александр Календарев

Насчет чистки диска уже задумался, т.к. есть вероятность того, что ответ
потребуется отдавать повторно. Буду использовать кеширование для этого.

За X-Accel-Redirect - спасибо. Думаю, заюзаю.

Кстати, попрофилировал скрипт и выяснил такую штуку: echo отрабатывает
довольно быстро вне зависимости от размера выводимого буфера. То есть мое
предположение о том, что echo выдается по мере скачивания ответа клиентом -
не подтвердилось. Видимо оно передается либо на уровень ОС, либо на уровень
веб-сервера и оттуда уже раздается дальше. Я, к сожалению, не сильно
разбираюсь в архитектуре. Соответственно, идея с выдачей через файлы и
экономией на памяти вероятнее всего не рабочая. Но в любом
случае X-Accel-Redirect реализую и о результатах - отпишусь.

2010/8/13 Alexandre Kalendarev <akalend@mail.ru>

> зачем чистить диск, если идет отдача постоянного контента
> мне кажется изначально стоит вопрос именно в том как защитить файлы от
> несанкционированного доступа
>
> хотя топикстартер от нас скрывают истинную цель
> что же ему надо в конечном итоге
>
> > Ключевое слово - X-Accel-Redirect
> > Но надо сразу задуматься над тем, как чистить диск от этих файлов.
>
> Александр Календарев
>
>


--
Арт@Антиблок
Анонимайзер Одноклассников и ВКонтакте
http://www.antiblock.ru
http://www.antizapret.ru
http://www.obhodilka.ru
http://www.obhodi.ru

On 08/13/10 10:32, Арт@Антиблок wrote:
> Кстати, попрофилировал скрипт и выяснил такую штуку: echo отрабатывает
> довольно быстро вне зависимости от размера выводимого буфера. То есть
> мое предположение о том, что echo выдается по мере скачивания ответа
> клиентом - не подтвердилось. Видимо оно передается либо на уровень ОС,
> либо на уровень веб-сервера и оттуда уже раздается дальше. Я, к
> сожалению, не сильно разбираюсь в архитектуре. Соответственно, идея с
> выдачей через файлы и экономией на памяти вероятнее всего не рабочая.
echo работает быстро, потому что отдаёт фронтенду (nginx), а не юзеру. А
nginx большой ответ складывает срачала во временный файл, потом отдаёт
юзеру. Поэтому имеет смысл положить в файл сразу и показать фронтенду
где он лежит, вместо того чтобы его содержимое по сети лишний раз
перекачивать.

В процессе возникла проблема следующего рода:

Использую библиотеку Zend.Http для скачивания файлов с удаленного хоста.
Собственно проект - хттп-анонимайзер. В случае с большими файлами возникает
следующая ситуация. Zend в цикле вызывает fread для сокета и скачивает
кусочки файла. В какой то момент возврата из функции fream банально не
происходит (аналогичное поведение и в случае с stream_copy_to_stream вместо
fread). Определил это расстановкой контрольных логирующих вызовов вокруг
нее. Логирование и вывод ошибок включены, и в случае каких либо ошибок
(синтаксис, нехватка памяти и т.п.) - все отображается. А тут - тупо
умирает. Подскажите способ, как определить что именно происходит? Какие логи
включать, какие тулы использовать? Уже сутки мучаюсь в поисках причины :)

Заранее благодарю!

2010/8/13 Andrey N. Oktyabrski <a.n.oktyabrski@gmail.com>

> On 08/13/10 10:32, Арт@Антиблок wrote:
>
>> Кстати, попрофилировал скрипт и выяснил такую штуку: echo отрабатывает
>> довольно быстро вне зависимости от размера выводимого буфера. То есть
>> мое предположение о том, что echo выдается по мере скачивания ответа
>> клиентом - не подтвердилось. Видимо оно передается либо на уровень ОС,
>> либо на уровень веб-сервера и оттуда уже раздается дальше. Я, к
>> сожалению, не сильно разбираюсь в архитектуре. Соответственно, идея с
>> выдачей через файлы и экономией на памяти вероятнее всего не рабочая.
>>
> echo работает быстро, потому что отдаёт фронтенду (nginx), а не юзеру. А
> nginx большой ответ складывает срачала во временный файл, потом отдаёт
> юзеру. Поэтому имеет смысл положить в файл сразу и показать фронтенду где он
> лежит, вместо того чтобы его содержимое по сети лишний раз перекачивать.
>

Проблему решил силами админа:

>> проблема была в настройках php-fpm, конкретно в этом параметре:
>> <value name="request_terminate_timeout">60s</value>
>> Т.е. грубо говоря было ограничение в 60 секунд на обработку запроса, хотя
в настройках php.ini ограничение выполнения скрипта установлено в 600.
>> Сейчас значение request_terminate_timeout установлено в 0s, т.е. без
ограничения и выполнение скриптов ограничивается только настройками php,
т.е. 600s.


2010/8/17 Art @ Впривате <art.vprivate@gmail.com>

> В процессе возникла проблема следующего рода:
>
> Использую библиотеку Zend.Http для скачивания файлов с удаленного хоста.
> Собственно проект - хттп-анонимайзер. В случае с большими файлами возникает
> следующая ситуация. Zend в цикле вызывает fread для сокета и скачивает
> кусочки файла. В какой то момент возврата из функции fream банально не
> происходит (аналогичное поведение и в случае с stream_copy_to_stream вместо
> fread). Определил это расстановкой контрольных логирующих вызовов вокруг
> нее. Логирование и вывод ошибок включены, и в случае каких либо ошибок
> (синтаксис, нехватка памяти и т.п.) - все отображается. А тут - тупо
> умирает. Подскажите способ, как определить что именно происходит? Какие логи
> включать, какие тулы использовать? Уже сутки мучаюсь в поисках причины :)
>
> Заранее благодарю!
>
> 2010/8/13 Andrey N. Oktyabrski <a.n.oktyabrski@gmail.com>
>
> On 08/13/10 10:32, Арт@Антиблок wrote:
>>
>>> Кстати, попрофилировал скрипт и выяснил такую штуку: echo отрабатывает
>>> довольно быстро вне зависимости от размера выводимого буфера. То есть
>>> мое предположение о том, что echo выдается по мере скачивания ответа
>>> клиентом - не подтвердилось. Видимо оно передается либо на уровень ОС,
>>> либо на уровень веб-сервера и оттуда уже раздается дальше. Я, к
>>> сожалению, не сильно разбираюсь в архитектуре. Соответственно, идея с
>>> выдачей через файлы и экономией на памяти вероятнее всего не рабочая.
>>>
>> echo работает быстро, потому что отдаёт фронтенду (nginx), а не юзеру. А
>> nginx большой ответ складывает срачала во временный файл, потом отдаёт
>> юзеру. Поэтому имеет смысл положить в файл сразу и показать фронтенду где он
>> лежит, вместо того чтобы его содержимое по сети лишний раз перекачивать.
>>
>
>